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@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries