Revamping the numeric classes

[andrew@andrewcooke.free-online.co.uk]

On Wed, Feb 07, 2001 at 11:47:11AM +0100, Ketil Malde wrote:
> "Ch. A. Herrmann" <herrmann@infosun.fmi.uni-passau.de> writes:
[...]
> > the problem is that the --majority, I suppose?-- of mathematicians
> > tend to overload operators. They use "*" for matrix-matrix
> > multiplication as well as for matrix-vector multiplication etc.
> Yes, obviously.  On the other hand, I think you could get far by
> defining (+) as an operator in a Group, (*) in a Ring, and so forth.

As a complete newbie can I add a few points?  They may be misguided,
but they may also help identify what appears obvious only through
use...

- understanding the hierarchy of classes (ie constanly referring to
Fig 5 in the report) takes a fair amount of effort.  It would have
been much clearer for me to have classes that simply listed the
required super classes (as suggested in an earlier post).

- even for me, no great mathematician, I found the forced inclusion of
certain classes irritating (in my case - effectively implementing
arithmetic on tuples - Enum made little sense and ordering is hacked
in order to be total; why do I need to define either to overload "+"?)

- what's the deal with fmap and map?

> Another problem is that the mathematical constructs include properties
> not easily encoded in Haskell, like commutativity, associativity, etc.
> 
> > I don't think that it is acceptable for a language like Haskell
> > to permit the user to overload predefined operators, like "*".

Do you mean that the numeric classes should be dropped or are you
talking about some other overloading procedure?

Isn't one popular use of Haskell to define/extend it to support small
domain-specific languages?  In those cases, overloading operatores via
the class mechanism is very useful - you can give the user concise,
but stll understandable, syntax for the problem domain.

I can see that overloading operators is not good in general purpose
libraries, unless carefully controlled, but that doesn't mean it is
always bad, or should always be strictly controlled.  Maybe the
programmer could decide what is appropriate, faced with a particular
problem, rather than a language designer, from more general
considerations?  Balance, as ever, is the key :-)

[...]
> >From experience, I guess there are probably issues that haven't
> crossed my mind.   :-)

This is certainly true in my case - I presumed there was some deep
reason for the complex hierarchy that exists at the moment.  It was a
surprise to see it questioned here.

Sorry if I've used the wrong terminology anywhere.  Hope the above
makes some sense.

Andrew

-- 
http://www.andrewcooke.free-online.co.uk/index.html


----- End forwarded message -----

-- 
http://www.andrewcooke.free-online.co.uk/index.html