Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] productivity improvement
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: brogoff@s...
Subject: Re: [Caml-list] Re: Camlp4 optimizations (was: productivity improvement)
On Thu, 17 Oct 2002, Chris Hecker wrote:
[...snip...]
> Overloading (operators and functions) would 
> help when writing certain kinds of programs, and I hope it gets added to 
> the language. 

I agree, and me too. 

Another related wish that comes up every so often would be the ability to 
have records in the same module which can share field names. Since we have 
polymorphic variants it seems that it isn't such a stretch to have more 
polymorphic records. Going to classes means you give up pattern matching, 
and pattern matching is one of the most attractive features of ML. I realize 
that some people will argue that the omission of overloading is a good thing 
from the standpoint of readability (I don't agree, but I understand this 
argument) but I have yet to see anyone make a similar claim about OCaml 
records. 

> Allowing infix function specification (instead of just 
> operators) would be nice as well for these same kinds of programs, but it 
> is not nearly as important (and it can be handled by camlp4 just fine).
> 
> Is there any news on the GCaml experiment from last year?

The online code hasn't changed for more than a year, and that old version 
doesn't really work with the module system. From playing with the system, 
I thought it was fine for the kind of overloading I wanted but but some people 
may have problems with the explicitness. I also wonder if there is an 
efficiency penalty. Consider that if you are interested in overloading + 
on integers, floats, and complex, no penalty is acceptable. 

There has, of course, been a lot more work on overloading in the Haskell 
world, with constraint handling rules, and systems O and CT and such. I 
doubt we'll see overloading in Caml anytime soon...

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners