Browse thread
Re: [Caml-list] productivity improvement
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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