<div dir="ltr">Darn, theres another carter on this list!!! (welcome!)<div class="gmail_extra"><br></div><div class="gmail_extra">These are some good points to push on, but *the two weeks* before ghc 7.8 is tentatively due for release! </div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Also,  3 is <b> too big</b> 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. </div>

<div class="gmail_extra"><br></div><div class="gmail_extra">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).</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">That said, I think after the split-base work lands, doing surgery on the default numerical classes becomes more tenable</div><div class="gmail_extra"><br></div>
<div class="gmail_extra">
cheers :) </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 23, 2014 at 10:13 PM, Carter Charbonneau <span dir="ltr"><<a href="mailto:zcarterc@gmail.com" target="_blank">zcarterc@gmail.com</a>></span> wrote:<br>

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