Proposal: Add log1p and expm1 to GHC.Float.Floating

Edward Kmett ekmett at gmail.com
Thu Apr 24 04:43:02 UTC 2014


I don't think that that works for my problem. In the end it just means that
I wind up opted out of using the feature, and forced to reason instance by
instance about if its safe. Worse its not just me stuck reasoning instance
by instance its the users of my libraries that could otherwise leverage
these benefits.

It is a passable solution for the end user who is writing an application
for a fixed instance or two, but as someone who produces a library consumed
by other users, we're just accumulating invariants that don't show up in
the types that they have to reason about, which strikes me as poor
engineering.

-Edward


On Thu, Apr 24, 2014 at 12:09 AM, wren romano <winterkoninkje at gmail.com>wrote:

> On Wed, Apr 23, 2014 at 11:55 PM, Edward Kmett <ekmett at gmail.com> wrote:
> > As a straw-man / olive-branch / half-baked idea:
> >
> > Could we get you what you want by simply making an extra class to
> indicate
> > the claim that the guarantee holds, and get what I want by placing these
> > methods in the existing Floating with the defaults?
>
> Another alternative along the same lines and just as ugly:
>
> * Introduce a new class for these high-precision methods.
> * Define a `newtype Dodgy a = Dodgy a` which gives the obvious but not
> necessarily precise implementations.
>
> Pros:
> * we don't have a class without methods
> * the providence of improved precision is made clear in the type (pro
> jlato/myself)
> * can use the interface even without improved precision (pro ekmett)
>
> Cons:
> * newtype noise whenever fallback is necessary. Individual functions
> are not affected by this noise, however the noise may leak into the
> rest of the program (contra ekmett, at least in spirit)
> * the desire for improved precision leaks into the types (contra ekmett)
> * can use the interface even without improved precision (this may seem
> conta the spirit of my/jlato's goals, but since the fallback is
> documented in the types it is therefore okay by me)
>
> --
> Live well,
> ~wren
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140424/f18ce4bd/attachment-0001.html>


More information about the Libraries mailing list