From: "Frank A. Christoph" <christo@nextsolution.co.jp>
To: "CAML Light List" <caml-light@pauillac.inria.fr>,
Subject: RE: Overloading
Date: Wed, 11 Mar 1998 05:28:34 +0900
> One of the things I miss the most when I'm working in Caml is
>overloading. There are numerous situations, such as arithmetic, linear
>algebra (where I may want multiplication between scalars, vectors,
>matrices, and higher order tensors), I/O (read/write/open), etc. where
>it is IMO the "right thing". Are there any plans to add some form of
>overloading to Caml in the future? I know that the Haskell folks plan to
>remove the single parameter restriction in type classes and gain more
>expressiveness in these areas, but none of the ML family of languages
>I know of support any overloading.
Are you working with Objective Caml or Caml Light? O'Caml has classes, and
the methods are overloaded with respect to the class type. Frankly, though,
I'm not sure that this style of overloading will be satisfactory for working
with algebra (and hence arithmetic), but only because of the syntax: you
have to use the postfix syntax as far as I know.
Objective Label, which is an O'Caml variant, supports polymorphic variants,
which work like constructors for intersection types. I think you might find
them quite useful, although it takes some time getting used to the
flexibility in the new type system.
Here's the O'Labl home page:
http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/
<<Warning: syntax complaint ahead>>
BTW, I have a question/suggestion for the designers of O'Caml's object
system. When referring to a method "m" from another method of an object,
one has to add an "as obj" phrase to the class declaration, and then refer
to "m" as "obj#m". When you refer to other methods often this way, it gets
tiresome and all the hashmarks are ugly.
I have one class that does pretty-printing and has a bunch of "convenience"
methods like "out_space" and "out_lparen": they aren't likely to be
overloaded, but they depend on the state so they can't be defined as
functions external to the class. After finishing the class, there were so
many extraneous hashmarks, etc. ("o#out s; o#out_rparen; o#out_space"...)
that I could barely read the source and I started to go to lengths to avoid
defining these things as methods, like making some of them function-valued
"val"'s until I realized that they couldn't access the state that way. When
I start avoiding semantic features because of the syntax, something is
wrong...
Is there some technical reason why the syntax for doing this can't be
shortened to just "#m" (or even better, just "m"---but I suspect the
hashmark is necessary to distinguish methods from functions)? I know that
in some other calculi, such as Abadi and Cardelli's, you need to mention the
object explicitly because a method might bind two different object
instances, but this case doesn't seem to occur in O'Caml's style of OO. I
don't see any confusion with superclasses, since you can still use the
explicit form in that case.
As an alternate idea, how about adopting the Smalltalk syntax, as someone
suggested some time ago?
o #m1 #m2 a #m3 b c
would be interpreted as
o#m1; o#m2 a; o#m3 b c
Or maybe this (interpreted as the same thing):
o#(m1; m2 a; m3 b c)
(I admit the first syntax is more elegant, but I hate the hashmarks...)
The sequencing operator is used so often, after all, in conjunction with
method invocation that I think it's not unreasonable to give it special
treatment here. It would also be nice to allow state updates mixed with the
method invocations, something like the Haskell monad do-syntax:
o#(m1;
mutstate <- mutstate';
m2)
(OK, maybe I'm reaching here.)
--FC
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:14 MET