Re: [Caml-list] ambitious proposal: polymorphic arithmetics

[Christophe TROESTLER <debian00@tiscali.be>]

On Wed, 06 Apr 2005, Eijiro Sumii <eijiro_sumii@anet.ne.jp> wrote:
> 

Well, I am not anywhere as much known as you are in the FP community
but let me jump in anyway! :)

> So here it goes: why don't we have polymorphic +, -, etc. while we
> have polymorphic =, <, etc.? [...] define +, -, etc. for as many
> types as possible such as integers, floating-point numbers, and tuples?

IMHO, the problem is not that much to have an handy set of polymorphic
operators than to be able to _extend_ them. See for example

http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/shootout/bench/implicitode/implicitode.ocaml?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=shootout

for a use of [open] and [let ... and ...] at the right places for the
expressions to look "nice" (e.g. [a * b] instead of [M.( * ) a b]).
In the mathematical world, this need occurs all the time.  E.g. you
define finite fields and want +, =,... to operate on those.  You also
want to define generic algorithms with those notions, e.g. power (as
of now, functors would be used for this).  The main difficulties
currently are that (1) it is difficult to use [open] at the right
places -- I have not checked whether the "openin" camlp4 extension can
handle unary and binary operators -- and (2) mixing the operators in a
single expression is impossible -- e.g. (a * b) * matrix.  However, I
would strongly like all this to be statically type checked -- no
exceptions _please_.  In fact, provided a suitable mechanism is found,
I would like = to stop throwing exceptions.

Personally I do not mid about +., *.,... even though admittedly they
are odd at the beginning.  But if 1 + 1.2 is going to throw an
exception, this is far far worse (simple typing mistakes will now
"crash" the program!!!).

> P.S. I believe I'm not proposing anything as serious as Haskell type
> classes.

Imagine how

  val plus : [| int -> int -> int
              | float -> float -> float |] = <generic>

will look once there are 10 types.  This is going to be even worse if
equality is to be _completely_ statically checked (as I desire).  I
only know superficially type classes, but

  (=) : Eq 'a => 'a -> 'a -> bool

is much more readable than

  (=) : [| int -> int -> bool
	 | float -> float -> bool
	 | 'a list -> 'a list -> bool
	 | ...                        |]

Moreover and more importantly, they can be extended (e.g. add Num.num
to the Eq class).  Also, "subclassing" should be possible (e.g. Ordered 'a
=> Eq 'a).  We are not allowing capitalized type names; this is a good
opportunity to use them!

In summary (since the opened the Pandora box), it would be nice if a
solution would be found to this "problem" but, let's go for a general
and useful one, not an had-oc one.  :)

Regards,
ChriS

---
P.S.  Maybe GADTs provide an alternative solution for named functions
but I believe not for binary operators.