On 15 April 2014 21:30, John David Reaver wrote:

...

why can i only "unsafely" create quantities using strings? what if i know upfront what kind of a unit i want to deal with? from the looks of it, this library is only good for dealing with human-readable input - surely that's not the only use case you had in mind?

...

can't we find some elegant way to express this in haskell, instead of having to invent a scripting language of sorts?

Using the type system to handle units is incorporated into some other libraries. I couldn't find a library that parses units from strings, so I made one. I certainly plan to add this functionality in the future.

so then why are you reinventing those units libraries? in other words, why did you write Quantity instead of reusing a similar data type from an existing library?

...

On a similar note, your "magnitude :: Quantity -> Double" sounds a bit like unsafeCoerce: why would you want to forget that your quantity has a unit?

You don't "forget" it has units. Sometimes you just want to get the magnitude, like after you perform a conversion operation, for instance.

but you do forget it has units! it says it right there: magnitude takes a Quantity, and gives back only the Double it contains. I don't know what definition of "forget" you're working with... your magnitude function suggests that to do some complicated calculation on some Quantity inputs, you first "unpack" them to Doubles, do your calculations, and then repack them into Quantities. that means my calculations are not type-safe against mixing up units anymore: why would we even store the unit of some number in the first place, if we have to (temporarily) forget those units the moment we start doing any serious calculations? Mind you: it is not acceptable to have to rewrite all my existing calculations to use your functions. I wrote +, I meant +, so I should be able to use + --- not your addQuants or subtractQuants. Maybe making Quantity an instance of the right type classes solves this entire issue?

...

Oh, so you are trying to support arbitrary arithmetical input! Then again, there is no way to add two "Quantity"s.

There is indeed: http://hackage.haskell.org/package/quantities-0.3.0/docs/Data-Quantities.htm... apologies, hadn't seen it.

However, that leaves me with the impression that there are two ways to add two quantities: "inside the string", such as with

...

...

...

fromString "ft + 12in" or in haskell, using addQuants.

Although it is of course perfectly allowed to implement the same functionality twice (yes, the same functionality: the essence is that you add two quantities. the fact that the exact input data is different doesn't bother me as a mathematician), this smells of bad library design. Not saying it is, just saying it leaves a bad taste: there is no clear reason why you need both. Again, what exactly is the purpose of your library?

...

I have the feeling the goal of your package is a bit unclear: do you want to implement a framework to type-safely compute with units? Or do you just want to write something that parses string input to typed data?

Currently, it parses string input. I am a contributor to a Python package called pint, which was a huge inspiration to this library.

my impression is that, in general, people try to stick with the unix mentality when it comes to designing the goals of a package: do one thing, and do it well. you are doing several things.

Most libraries only support static checking of units (AFAIK).

I found that to be the case. Indeed, if would be nice to integrate both approaches elegantly. I haven't figured out how yet.

(try to type "(1m + 1ft + 2 yards + 50in) * 5 / (8 km/h) in minutes" for instance).

I had to try it using quantities :)

...

...

fromString "(1m + 1ft + 2 yard + 50in) * 5 / (8 km/h) => minute" Right 0.16513500000000006 minute