Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] Future of labels
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-04-03 (20:13)
From: Chris Hecker <checker@d...>
Subject: Re: [Caml-list] Generics?

>I'm confused by your use of the term "generics", which I've seen in
>another of your posts as well. Care to explain to the uninitiated? 

I would definitely be one of the uninitiated as well.  :)

I should point out, as I said in my original post ages ago asking about the status of these features, that the generics thing is a little cloudy in my mind (as opposed to overloading and module recursion).  I'll mumble a bit and then maybe somebody with more of a clue can help out.

I first started thinking about this when I was trying to wrap my head around the difference between Caml style polymorphism and C++ templates.  Basically, if I write a sort routine in Caml, I need to pass in the comparator as a closure (not really, because </>/compare/etc. are polymorphic themselves, but hopefully you get the general idea).  Now, ignoring overloaded operators, in the C++ sort function you'd just type if(compare(a,b)) { ... } and the compare(type,type) function would have to be declared somewhere for the type you're sorting, but you don't have to pass compare to the sort.

There are pros and cons of both ways, as far as I can tell.  The Caml way lets you totally decouple the sort function from the code that calls it, whereas in current C++ implementations you basically need to have the sort function in a header file because it resolves compare() by name at the time of compilation.  On the other hand, in Caml I have to pass closures around all over the place, and for a simple case like compare(), I get a function call per comparison while the C++ case is easy to inline and generate optimal code as if the specific typed versions were hand written.

So anyway, I guess I want the best of both types (excuse the pun) of polymorphism/genericity.  I'm not exactly sure what "the best of both" looks like, however, so I'm not exactly sure what I want.  When I was thinking about this before, I ran across some good posts on the subject in the archive.

I guess a partial specification of "the best of both" would be that if all the information was available statically, then I'd like the optimal code to be generated, like C++.  If I stick a generic function into a datastructure or pass it as a closure, then I'm fine with the runtime checks that the second message above implies.

To take a slightly higher level view, I'd like to be able to do some of the generic programming stuff that Stepanov had in mind when he designed the STL.  I don't see how to do that without overloading and some kind of generic facility (or maybe overloading is enough, not sure).  Passing closures isn't really the same thing.

Vague enough for you?  :)


To unsubscribe, mail  Archives: