Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add parsing functionality (possible in a new package) #230

Open
LaurentRDC opened this issue Nov 27, 2024 · 4 comments
Open

Add parsing functionality (possible in a new package) #230

LaurentRDC opened this issue Nov 27, 2024 · 4 comments

Comments

@LaurentRDC
Copy link
Collaborator

One source of problems when dealing with units at the boundary between the user and a program, or between programs. However, there is currently no way to parse Quantity and Unit from unstructured text.

@bjornbm Would you be OK if this repository contained two packages, dimensional and possibly dimensional-parsing?

@bjornbm
Copy link
Owner

bjornbm commented Nov 27, 2024

Could you show me an example of what you have in mind as API/usage?

Maybe take a look At @dmcclean’s
https://github.com/dmcclean/dimensional-parsers to check whether it seems complete and/or salvageable.

@dmcclean maybe you can comment?

@LaurentRDC
Copy link
Collaborator Author

Thanks for linking previous work.

Ideally, the parsing interface would be more type-safe than dimensional-parsers, avoiding dynamic quantities and units. Something like:

parseQuantity :: Text -> Either Error (Quantity d a)

where the user must specify what dimension d is expected, and parseQuantity failing if the input Text doesn't represent this dimension.

I haven't thought how that would work in practice though

@LaurentRDC
Copy link
Collaborator Author

Related issue: #8

@bjornbm
Copy link
Owner

bjornbm commented Nov 27, 2024

Ideally, the parsing interface would be more type-safe than dimensional-parsers, avoiding dynamic quantities and units.

It seems it could make sense to parse to a DynQuantity and then fmap promoteQuantity to give you the type safety?

Convoluted (and untested) use case for DynQuantity parsing:

getVelocity :: Num a => Text -> Text -> Either Error (Power a)
getVelocity input1 input2 = do
   x <- parseDynQuantity input1
   y <- parseDynQuantity input2
   promoteQuantity (x * y)   -- see note

This allows the inputs to be a force and a velocity, or a torque and an angular velocity, or a current and a voltage.

Note: I took the liberty to disregard that promoteQuantity returns a Maybe – I think there would be no objection to changing this to a Monad m.

Anyway, I don't feel very strongly about this.

Maybe the first step is to determine your level of ambition… as indicated in #8 parsing units can get hairy.

I can also see how it could be nice to have a parse/read capability with lighter dependencies than dimensional-parsers for less demanding cases. If very light/no dependencies it could maybe be included in the dimensional package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants