On Thu, 14 Sep 2006, David Menendez wrote: > Ross Paterson writes: > > > On Thu, Sep 14, 2006 at 01:11:56AM -0400, David Menendez wrote: > > > Coincidentally, I spent some time last week thinking about a > > > replacement for the Num class. I think I managed to come up with > > > something that's more flexible than Num, but still mostly > > > comprehensible. > > > > The fact that the first part of your structure is much the same as > > the one on the web page (which is essentially that part of the revised > > numeric prelude plus a Haskell 98-compatible veneer) is evidence that > > it's pretty clear what to do with Num and Fractional. > > That being said, I don't expect anything to change. > > I've looked through the revised numeric prelude, but the qualified class > names put me off.
Just consequent usage of: http://www.haskell.org/hawiki/UsingQualifiedNames > Everything shows up in Haddock as "C". That's a problem. I recently tried to extend Haddock to showing qualifications. But this turned out to be more complicated than I expected. > Also, it doesn't support naturals--which, admittedly, is not a big loss. Simple to add. It will certainly be added. > > The only point of contention is whether to factor out monoid and > > semiring classes. Arguments against include: > > > > * There are lots of monoids, and (+) doesn't seem a reasonable symbol > > for some of them. > > True enough. (At least it's more general than "mappend".) > > I would expect all the more specific monoid operators, like (||) and > (++), to stick around for readability when not writing > non-monoid-generic code. Not to mention that (+) and (++) associate > differently. I think we should separate the names of the functions which implement some operation from the method names. That is, (||) should be the name for the implementation of Bool-OR, and could also be 'or' (if this wouldn't be given to the list function) and (+) is the name of the corresponding Monoid method. If I want to write a generic monoid algorithm I have to use (+), otherwise I use (||) for type safety. It's just the same like 'map' and 'fmap'. However writing accidentally (a+b) if a and b are Bool will no longer be reported as type error. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe