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.