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: | Sven Luther <luther@d...> |
| Subject: | Re: [Caml-list] Re: Camlp4 optimizations (was: productivity improvement) |
On Fri, Oct 18, 2002 at 10:23:32AM +0200, Remi VANICAT wrote: > Alessandro Baretta <alex@baretta.com> writes: > > > Jeffrey Palmer wrote: > >> On Thursday 17 October 2002 6:55 pm, Alessandro Baretta wrote: > >> Hmm. I have two observations: > >> 1) You can't "use" templates without instantiating them, so although > >> you're right - template type checking is deferred to instantiation, > >> this is by design (a pain, I agree). > > > > It's more than a pain. John Max Skaller acutely pointed out that > > templates have "no semantics". The semantics of a template depends on > > the parameter(s) with which it is instantiated, and in a very bizzarre > > way. Code which compiles and is correct with well-behaved > > parameters--the STL, for example--becomes incorrect, won't compile, or > > will miserably die at runtime with a segfault, if it is instantiated > > with a parameter class redefining the basic operations--equality, > > assignment, copy constructor, etc--in a such a way as to violate the > > assumptions explicitly or implicitly made by the template > > designer. Such errors are not revealed when the template is written > > and "compiled". They are revealed at best at template instantiation > > time, and possibly at runtime. > > > > Caml functors, on the other hand, are statically type checked at > > compile time. Once and for all. If they compile, they're correct. And > > that's it. > > > Well, the Set.Make and Map.Make functor to the stdlib want the compare > function of their argument to be a comparison function. This in not > checked at compile time (this can't be verify). and if this not the > case, you can difficultly predict the comportment of those functor. > (well it won't segfault, but it may not do what you want). It will just do what you tell it to do, which is a feature, not a bug :))) Friendly, Sven Luther ------------------- 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