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 SAA04730; Fri, 19 Jul 2002 18:35:12 +0200 (MET DST) 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 SAA04739 for ; Fri, 19 Jul 2002 18:35:11 +0200 (MET DST) Received: from bastion.artisan.com (bastion.artisan.com [209.144.161.130]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g6JGZAj28862 for ; Fri, 19 Jul 2002 18:35:10 +0200 (MET DST) Received: from ypmaster.artisan.com (ypmaster [172.16.2.1]) by bastion.artisan.com (8.9.2/8.9.2) with ESMTP id JAA18344 for ; Fri, 19 Jul 2002 09:35:07 -0700 (PDT) Received: from granite.artisan.com (granite [172.16.10.97]) by ypmaster.artisan.com (8.9.2/8.9.2-arti) with ESMTP id JAA08152 for ; Fri, 19 Jul 2002 09:35:07 -0700 (PDT) Received: (from bpr@localhost) by granite.artisan.com (8.9.2/8.9.2) id JAA14461; Fri, 19 Jul 2002 09:35:07 -0700 (PDT) X-Authentication-Warning: granite.artisan.com: bpr set sender to bpr@artisan.com using -f From: Brian Rogoff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15672.16315.119498.683662@granite.artisan.com> Date: Fri, 19 Jul 2002 09:35:07 -0700 To: caml-list@inria.fr Subject: Re: [Caml-list] productivity improvement References: <20020716172916.4903.qmail@web10702.mail.yahoo.com> <200207182313.TAA19905@dewberry.cc.columbia.edu> <20020718235405.GA22176@force.stwing.upenn.edu> X-Mailer: VM 7.00 under Emacs 20.7.1 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk William Lovas writes: > It strikes me that although you were able to quite easily translate this > toy evaluator example into C++, this may not have been the case with a > larger, more complex example. Even this toy example was not really translated into C++. Translating OCaml functions, which can be closures, to C style function pointers, is a cheat. To be accurate, you need to model these as C++ functors (yes, I hate that terminology but that's what Stroustrup uses) to simulate closures. This is inevitably a pain, because simulating nested functions in a lexically scoped language means that the object constructor has to have the variables that the "execute" function uses explicitly passed in. > It's something that scales exponentially, so you're probably not going to > find very many small, concise examples that show conclusively how much > easier O'Caml is. Actually, I think that there are quite a few. Anyways, if you're interested in pursuing the extensibility question raised here further, Jacques Garrigue wrote a nice little paper comparing sum types, polymorphic variants, and classes on a simple evaluator example. http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/fose2000.html -- 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