[Caml-list] Suggestion for overloaded operators

[Caml-list] Suggestion for overloaded operators

[Warp]

Helo.
One of missing thing in Ocaml is the possibility to overload the operators
such as + - / * = (by overloading, i mean : defining such operators for
other types than -int- )....
Here's a syntactic proposal to enable this feature :

(a :+ b)
The ':' is here to precise that we're using overloading , and a and b can be
of any type. ( let's say typea and typeb )
The compiler will seek for a function named :
    typea_add_typeb : typea -> typeb -> typer
and use it to implement the :+ operator. ( which have typer as result type )
And so on...

I think such a thing cannot be done with CamlP4 - because it doesn't know
about types - and I know that the ocaml team has lots of things to do , but
I was thinking that can be a quite good feature for futur updates.

Warp

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for overloaded operators

[Alain Frisch]

On Sun, 10 Feb 2002, Warp wrote:

> Helo.
> One of missing thing in Ocaml is the possibility to overload the operators
> such as + - / * = (by overloading, i mean : defining such operators for
> other types than -int- )....
> Here's a syntactic proposal to enable this feature :

You say nothing about the typing of static overloading (interaction with
polymorphism and type inference), and this is the crux of the matter.

What type would you give to:
fun a b -> a :+ b
?

This expression has many possible types, and no best one.

Even when the context could allow to statically resolve the overloading,
this may be beyond the current type inference algorithm. For instance:

fun a b -> let r = a :+ b in a + b + r

The end of the expression allows to deduce that a and b are int, but
when :+ is typed, this information is not yet available.

A simple minded solution is to require that enough type information
is available to resolve the overloading at the point where the algorithm
encounters it. This is very similar to the patch I posted to this list
about overloading of record labels, and the same arguments against it
apply as well.


Maybe you should have a look at G'Caml:
http://pauillac.inria.fr/~furuse/generics/


-- Alain

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for overloaded operators

[Warp]

> > Helo.
> > One of missing thing in Ocaml is the possibility to overload the
operators
> > such as + - / * = (by overloading, i mean : defining such operators for
> > other types than -int- )....
> > Here's a syntactic proposal to enable this feature :
>
> You say nothing about the typing of static overloading (interaction with
> polymorphism and type inference), and this is the crux of the matter.

Actually this was only a syntactic suggestion for overload. I don't know
well enough the ocaml typing algorithms to suggest the correct way to
implement it and to solve problems such as :

> What type would you give to:
> fun a b -> a :+ b
> ?

Warp

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for overloaded operators

[Bruno Pagano]

On Sun, Feb 10, 2002 at 02:04:45PM +0100, Warp wrote:
> Helo.
> One of missing thing in Ocaml is the possibility to overload the operators
> such as + - / * = (by overloading, i mean : defining such operators for
> other types than -int- )....
> Here's a syntactic proposal to enable this feature :
> 
> (a :+ b)
> The ':' is here to precise that we're using overloading , and a and b can be
> of any type. ( let's say typea and typeb )
> The compiler will seek for a function named :
>     typea_add_typeb : typea -> typeb -> typer
> and use it to implement the :+ operator. ( which have typer as result type )
> And so on...
> 
> I think such a thing cannot be done with CamlP4 - because it doesn't know
> about types - and I know that the ocaml team has lots of things to do , but
> I was thinking that can be a quite good feature for futur updates.
> 
> Warp
> 
> -------------------
> Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
> To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Hello,

  what about polymorphism ?

assume following declarations :

let (:+) x y = x + y 
let (:+) x y = x +. y

we define the overloaded operator :+  (respectively for int and for float)

what about the following declaration :

let f x y = x :+ y ;;

Is f overloaded too ?  f has not the colon symbol !
Is this declaration forbidden ? why !

I think that overloading is not compatible with type inference  ?

Bruno Pagano

PS: Perhaps, type inference is no more relevant with modules and objects
and should disappear !
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for overloaded operators

[Warp]

> Hello,
>
>   what about polymorphism ?
>
> assume following declarations :
>
> let (:+) x y = x + y
> let (:+) x y = x +. y
>
> we define the overloaded operator :+  (respectively for int and for float)

here, you can't do that because :+ is not an operator.

let int_add_int x y = x + y
let float_add_float x y = x +. y


> what about the following declaration :
>
> let f x y = x :+ y ;;

f : 'a -> 'b -> 'c
and assume that a function called   typea_add_typeb exists and returns a 'c
type.

 > Is f overloaded too ?  f has not the colon symbol !
> Is this declaration forbidden ? why !
>
> I think that overloading is not compatible with type inference  ?

I don't know, but this thread should answer to that question.

Warp

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for overloaded operators

[Tom]

> Here's a syntactic proposal to enable this feature :
> 
> (a :+ b)
> The ':' is here to precise that we're using overloading , and a and b can be
> of any type. ( let's say typea and typeb )

I don't see why overloading should just apply to operators;
it can just as well apply to functions.

More importantly, the problem isn't coming up with a syntax
or indicating that something is overloaded, the problem is
doing the type checking efficiently in the presence of 
type variables.

SML/NJ and Haskell each have partial solutions to the problem.
You may want to look there.

Tom


__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for overloaded operators

[Francois Pottier]

On Sun, Feb 10, 2002 at 02:04:45PM +0100, Warp wrote:
>
> The compiler will seek for a function named :
>     typea_add_typeb : typea -> typeb -> typer

Your proposal is reasonable, but you forget that typea and typeb might be
unknown, and might remain unknown for quite a while. For this reason,
overloading poses a difficult type inference problem. One elegant way to solve
it is embodied by Haskell's type classes:

  P. Wadler and S. Blott.
  How to make ad-hoc polymorphism less ad-hoc. 
  ftp://ftp.dcs.gla.ac.uk/pub/glasgow-fp/authors/Philip_Wadler/how-to-make-ad-hoc-poly-less-ad-hoc.dvi

You may also wish to have a look at another interesting paper on the
topic:

  Martin Odersky, Philip Wadler, and Martin Wehr.
  A second look at overloading.
  http://lampwww.epfl.ch/~odersky/papers/fpca95.ps.gz

Cheers,

-- 
François Pottier
Francois.Pottier@inria.fr
http://pauillac.inria.fr/~fpottier/
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr