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
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