Burning more bridges (mostly numeric ones)

Carter Schonwald carter.schonwald at gmail.com
Mon Feb 24 04:13:52 UTC 2014


Darn, theres another carter on this list!!! (welcome!)

These are some good points to push on, but *the two weeks* before ghc 7.8
is tentatively due for release!

Also,  3 is * too big* to be included in this thread, the ones before are
worth several threads alone. I humbly ask all subsequent respondents to
focus on #'s 1 and 2.

fixing the numeric components of prelude actually will require some
innovation on the way we can even organize / structure type classes if we
really wish to map the standard pen+paper algebraic structures to their
computational analogues in  a prelude friendly way. I've got many good
reasons to care about improving this piece of Base, including the fact that
I'm spending (a professionally inadvisable) large amount of time figuring
out how to improve the entire numerical computing substrate for Haskell.
And i'm leaning towards figuring out the numeric prelude that needs to be
*correct and good* and then pushing for a subset thereof for getting into
base. This is one of those areas that "commitee"  doesn't matter. the
design has to work. It has to be useable. And i don't think theres
currently any strong "heres the right design" choice.  Also whatever new
design lands in GHC BASE defacto determines the next haskell standard
(ishhh).

That said, I think after the split-base work lands, doing surgery on the
default numerical classes becomes more tenable

cheers :)


On Sun, Feb 23, 2014 at 10:13 PM, Carter Charbonneau <zcarterc at gmail.com>wrote:

> The Burning Bridges thread got lots done, but seemed to miss a few things,
> and
> didn't even touch on the Numeric classes. The Numeric classes should be
> fixed
> at some point, and sooner is better than later. However, it would be a
> large
> change and would go nicely with a major version bump in base. 5 is coming
> up soon. Proposals, ordered from relatively controversial to insanely so
> (at least IMO):
>
> 1. Replace (.) and id from versions from Control.Category in Prelude
>   This is a small change, and has close to the same effect as the Foldable/
>   Traversable change. The key difference is that this is a much smaller
> change
>   and there is little current use for the versions from Control.Category
>   However, historically they have seen use with the other lens-ish
> libraries,
>   and AFAICT are the reason the lenses in `lens` are "backwards", or at
> least
>   called so my some.
>
> 1.2 Use Semigroupoid for (.) and Ob for id instead. Personally, I really
> like
>    this idea, but I think it would be much more controversial.
>
> 2. Move Semigroup into Prelude
>
> 2.1 Make Monoid depend on Semigroup.
>
> 3. Do something with the Numeric classes. This isn't so much of a proposal
> as a
>   request for discussion from people more experienced than me, but I still
>   think a general idea if people think that doing *anything* is a good idea
>   would be useful.
>
> 3.1 Split each numeric operation into it's own class. Say no to 3.2 and
> yes here
>    for no hierarchy in them/ConstraintKinds/empty classes.
>    Pros: EDSLs, convenience.
>    Cons: Would be major breakage, would need ConstraintKinds/empty classes
> to
>          have a hierarchy.
>
> 3.2 Hierarchy. the classes are TBD, this is here for a straw poll.
>
>
> _______________________________________________
> 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/20140223/dbf53ff7/attachment.html>


More information about the Libraries mailing list