<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-04-15 22:54 GMT+02:00 Auke Booij <span dir="ltr"><<a href="mailto:auke@tulcod.com" target="_blank">auke@tulcod.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">On 15 April 2014 21:30, John David Reaver <<a href="mailto:jdreaver@adlerhorst.com">jdreaver@adlerhorst.com</a>> wrote:<br>
<br>
> Using the type system to handle units is incorporated into some<br>
> other libraries. I couldn't find a library that parses units from<br>
> strings, so I made one. I certainly plan to add this<br>
> functionality in the future.<br>
<br>
</div>so then why are you reinventing those units libraries? in other words,<br>
why did you write Quantity instead of reusing a similar data type from<br>
an existing library?<br></blockquote></div><br>Most libraries only support static checking of units (AFAIK). Supporting unit parsing from a string is great. When we will rewrite Google with Haskell, we will need it ;) (try to type "(1m + 1ft + 2 yards + 50in) * 5 / (8 km/h) in minutes" for instance).<br>
<br>You cannot ask him why his library only supports string input, then ask him to provide an additional Haskell DSL that is not unsafe and finally reproach him for wanting to support both approaches. For his needs (at least in the Python GUI app he describes), he can either use an external DSL approach (parsing strings) or use an Haskell EDSL with System.Eval.Haskell (or an equivalent). The former may be preferred.<br>
<br>-- Sylvain<br></div></div>