RE: Overloading

RE: Overloading

[Frank A. Christoph]

> 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

Overloading

[Brian Rogoff]

(My apologies for the lack of a French version of this message)

Hi Caml'ers,
	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.

	My experience with overloading in Ada is almost entirely positive.

-- Brian

Overloading

[Adam P. Jenkins]

Brian Rogoff writes:
 > (My apologies for the lack of a French version of this message)
Same here.

 > 
 > Hi Caml'ers,
 > 	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.
 > 
 > 	My experience with overloading in Ada is almost entirely positive.
 > 

I too have missed overloading in ML/Caml.  However, it seems to me
that function overloading is opposed to type inference; you can't have
both at the same time without too many explicit casts, which destroys
the point of function overloading.  Are there any languages which have
both automatic type inference and function overloading?

Adam

Re: Overloading

[Brian Rogoff]

On Tue, 10 Mar 1998, Adam P. Jenkins wrote:
> Brian Rogoff writes:
>  > Hi Caml'ers,
>  > 	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.
>  > 
>  > 	My experience with overloading in Ada is almost entirely positive.
>  > 
> 
> I too have missed overloading in ML/Caml.  However, it seems to me
> that function overloading is opposed to type inference; you can't have
> both at the same time without too many explicit casts, which destroys
> the point of function overloading.

Yes, I know the marriage of the type inference and overloading is a
difficult one. 

> Are there any languages which have
> both automatic type inference and function overloading?
> 
> Adam

Haskell has some limited ad-hoc polymorphism via its type classes, and 
there was some work at adding a form of ad-hoc polymorphism to Caml. It is 
on the Caml page, look for "extensional" polymorphism. I haven't read it
yet. Perhaps some of the Caml implementors can comment on what it
describes. Also under Francois Rouaix's page is a description of "Alcool", 
which has another approach to overloading in an ML like language.

C++ (which has overloading) supports a limited form of type inference for 
templated functions. There was a proposal to add something similar to Ada 
in an old Tri-Ada proceedings. It is usually called "automatic instantiation"
or something similar in those communities. 

In response to Frank Christoph, I am using O'Caml. What I really want in 
this case is overloading, not OO. I think the reasons for this desire and 
the arguments for overloading are known, so I won't repeat them unless 
someone wants me to. I have seen O'Labl, but since I use Windows NT at 
home I haven't used it yet (when I get Linux that will change ;-). It
looks very promising, and I also miss named parameters from Ada, but
still, it isn't quite what I want.

-- Brian

Re: Overloading

[Jun P. Furuse]

Brian Rogoff wrote:

> there was some work at adding a form of ad-hoc polymorphism to Caml. It is 
> on the Caml page, look for "extensional" polymorphism. I haven't read it
> yet. Perhaps some of the Caml implementors can comment on what it
> describes. 

As they described in their paper[1], there is an extended version
of Caml-light for "extensional polymorphism". But I don't know it is
FTP or HTTP-available.

I am now tring to implement ad-hoc polymorphism / overloading on
O'Caml. It will be partially based on the system described in the
paper, but somewhat improved hopefully. I will be able to release a
prototype this summer or at least at the end of this year. But of
course I don't know it will be integrated in the official O'Caml
release...

[1] ftp://ftp.inria.fr/INRIA/Projects/cristal/Francois.Rouaix/generics.dvi.Z

-----------------------------------------------------------------------
Jun P. Furuse 					 Jun.Furuse@inria.fr
  INRIA
    Institut National de Recherche en Informatique et en Automatique