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 PAA21024; Sun, 26 Sep 2004 15:10:22 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA21196 for ; Sun, 26 Sep 2004 15:10:21 +0200 (MET DST) Received: from ptb-relay03.plus.net (ptb-relay03.plus.net [212.159.14.214]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i8QDALV7002758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Sep 2004 15:10:21 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay03.plus.net with esmtp (Exim) id 1CBYnC-000Fby-UI for caml-list@inria.fr; Sun, 26 Sep 2004 13:10:19 +0000 From: Jon Harrop To: caml-list@inria.fr Subject: Re: [Caml-list] C++ STL and template features compared with OCaml parametric polymorphism and OO features Date: Sun, 26 Sep 2004 14:05:37 +0100 User-Agent: KMail/1.6.2 References: <20040925225246.48566.qmail@web53010.mail.yahoo.com> <200409260234.50929.jon@jdh30.plus.com> <7f8e92aa04092522313d47820d@mail.gmail.com> In-Reply-To: <7f8e92aa04092522313d47820d@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409261405.37558.jon@jdh30.plus.com> X-Miltered: at concorde with ID 4156BFBD.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 2004:99 compile-time:01 commonality:01 hofs:01 hofs:01 higher-order:01 practicable:01 implemented:01 verbose:01 variance:01 entropy:01 equivalents:01 ocaml:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sunday 26 September 2004 06:31, Radu Grigore wrote: > The resulting C++ code is still uglyer than its OCaml counterpart. And > longer. But you should notice that the same accumulate function is > used for three different containers, while in OCaml you use one > function for each container type. My "sum" function was used for all container types. Indeed, that was the point... :-) If you don't want to supply the container-specific fold at compile-time (e.g. with "sum List.fold_left ...") then you can use some form of RTTI, most obviously objects: let sum c = c#fold_left ( +. ) 0. c But, essentially, this is a problem of factoring code. We wish to factor the commonality of operations over different types of container. Iterators are only one way to do this and this approach is only suitable in the absence of HOFs (IMHO) and in the presence of imperative style. If you have HOFs, you just write my "sum" function and get on with something more interesting. > OTOH, something that is maybe less > obvious in the code above, I do use conainer specific functions in > C++: namely begin and end. Also, note that the C++ version uses "accumulate" which is effectively equivalent to "folding with addition". In OCaml, you can fold using any function you want, or write a higher-order function which folds over a given function. This is possible but, IMHO, not practicable in C++. > So, in short: In OCaml you don't have iterators so the fold method is > container specific. In C++ you have iterators that allow a > container-independent "fold-like" function to be implemented. The C++ > program is more verbose. My example is also borderline. Virtually anything more complicated that this will widen the gap between C++ and OCaml. Consider computing the variance of a given container of integers using rational arithmetic, or computing the "n"th nearest neighbours in a graph, or writing a function minimisation algorithm, the maximum entropy method... > Using C++'s header (or Boost.Lambda for that matter) is > sure to give you a headache after programming a bit in a functional > language like OCaml. But the same can be said about writting > imperative code in OCaml. I'd contest that. I use mutables for things like testing that some operation was done at least once by an otherwise functional function. I haven't had any headaches... > I have recently compared two implementations of the same small program > in C++ and OCaml, both written by me. The OCaml one was 45% the size > of the C++ one (byte count). After compression (with bzip2) it was > 67%. And it was kind of imperative job so C++ should have been in > advantage there. And I know C++ much better than OCaml, so this should > have been another advantage.. I'm finding that OCaml code is much more concise than that. My imperative-style vector graphics engine in about 1/4 the size than the C++ version and includes much more functionality. My other work simply cannot feasibly be written in C/C++ due to the incidental complexity of lexing, parsing and interpreting in such languages. Also, for any >1 month programming tasks, my OCaml code is _always_ faster than my C++ equivalents were. Cheers, Jon. ------------------- 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