From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id AD36EBC6B for ; Thu, 28 Jun 2007 13:18:27 +0200 (CEST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5SBIRm1027939 for ; Thu, 28 Jun 2007 13:18:27 +0200 Received: from [141.84.136.30] (helo=[152.78.96.56]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1I3s142pl3-0004Cs; Thu, 28 Jun 2007 13:18:26 +0200 Message-ID: <46839914.2000102@functionality.de> Date: Thu, 28 Jun 2007 12:18:44 +0100 From: Thomas Fischbacher User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060607 Debian/1.7.12-1.2 X-Accept-Language: en MIME-Version: 1.0 To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] The Implicit Accumulator: a design pattern using optional arguments References: <200706271314.35134.jon@ffconsultancy.com> <200706271618.54156.jon@ffconsultancy.com> <468293D4.3000100@functionality.de> <200706271917.55344.jon@ffconsultancy.com> In-Reply-To: <200706271917.55344.jon@ffconsultancy.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/vBdSaYMd2mZrA5hwJySxNiifjsdfSbTZyPei lQSq2x6Cecy+7wiHW8oCqq5ClSGeoPiT57tuUc00JQ5bUaR9QX ppUtBJPqZusGHYfY4dtsQ== X-Miltered: at concorde with ID 46839903.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; stack:01 constructors:01 constructors:01 ocaml:01 ocaml:01 deallocation:01 emacs:01 suck:98 wrote:01 dynamically:01 caml-list:01 lisp:01 lisp:01 closure:01 match:02 Jon Harrop wrote: >>In order to avoid dynamic memory management and get dynamically scoped >>pre-allocated "implicit context" buffers to which I can refer as if they >>were ordinary variables. > > > Do you mean something like this: > > let dt() = > let start = ref (time()) in > fun () -> > let time' = time() in > let dt = time' -. !start in > start := time'; > dt > > Call dt() to get a new delta timer, call the delta timer to get the time since > it was last called: Here, you are just packing state into a closure, so effectively you build an "object". I am talking about attaching "contextual state" to the dynamical call stack, which is a completely unrelated issue. >>>Weren't values and multiple-value-bind completely superceded by pattern >>>matching? >> >>No. :-) Pattern matching requires constructors, which cons. > > > Here is a pattern match without constructors: > > let x = 3 > > Here is a pattern match that doesn't cons: > > let f(x, y) = x + y in > f 3 4 And, incidentally, also does not work. > Here is a pattern match with constructors that doesn't cons: > > type t = A | B > > let f = function > | A -> 0 > | B -> 1 You are evading the question. How do you return two arguments from a function without constructing a 2-tuple (which is a consing operation). A continuation call to a higher order function is one way to get something similar to MULTIPLE-VALUE-*. But often, this is a hack. > What exactly are you having trouble implementing in OCaml? It sounds as if > you're still trying to work around the inefficiencies of Lisp and the beauty > of OCaml is that you don't have to. :-) > Incidentally, the ray tracer is a good demonstration of this. The performance > of the Lisp implementations is crippled by very slow allocation and > deallocation. Juho Snellman tried to circumvent this problem using > multiple-value-bind in a macro: Jon, you still don't get it. OCaml is just another language among a whole zoo which also contains many other interesting systems. I know you would like to believe otherwise, but it certainly is not the hottest invention since fire and the wheel. I often use it myself professionally and non-professionally, for a variety of purposes and projects, but then only because some thought on the structure of the problem at hand has shown that among all the tools that suck (all programming languages do), OCaml turned out to be the one that sucked least. To me, sometimes, it's Java that sucks least, sometimes it is Emacs (Lisp), sometimes Common LISP, and sometimes Perl. > While this greatly improves the performance of the Lisp, it remains far slower > than most other languages. According to your usually-screwed-up metrics, I suppose OCaml must then even be faster than Michael Schuhmacher. :-) -- Thomas Fischbacher tf@functionality.de