From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA32264; Tue, 3 Apr 2001 22:13:05 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA32257 for ; Tue, 3 Apr 2001 22:13:04 +0200 (MET DST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f33KD2P15263 for ; Tue, 3 Apr 2001 22:13:03 +0200 (MET DST) Received: from checkerlap.d6.com ([64.163.212.241]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0GB8002RKG4K1Z@mta6.snfc21.pbi.net> for caml-list@inria.fr; Tue, 3 Apr 2001 13:12:21 -0700 (PDT) Date: Tue, 03 Apr 2001 13:12:11 -0700 From: Chris Hecker Subject: Re: [Caml-list] Generics? In-reply-to: X-Sender: def6@shell16.ba.best.com To: Brian Rogoff Cc: caml-list@inria.fr Message-id: <4.3.2.7.2.20010403124151.03427af0@shell16.ba.best.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Content-type: text/plain; charset="us-ascii" References: <4.3.2.7.2.20010402232928.00d3b180@shell16.ba.best.com> Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >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. http://caml.inria.fr/archives/199803/msg00011.html http://caml.inria.fr/archives/200004/msg00122.html 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? :) Chris ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr