[Haskell-cafe] [Haskell] [ANN] quantities 0.3.0
auke at tulcod.com
Tue Apr 15 20:54:09 UTC 2014
On 15 April 2014 21:30, John David Reaver <jdreaver at adlerhorst.com> 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
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
>> Oh, so you are trying to support arbitrary arithmetical input!
>> Then again, there is no way to add two "Quantity"s.
> There is indeed:
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.
More information about the Haskell-Cafe