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=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id F3857BC0B for ; Mon, 15 Jan 2007 07:12:25 +0100 (CET) Received: from ipmail02.adl2.internode.on.net (ipmail02.adl2.internode.on.net [203.16.214.141]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0F6CNNv018059 for ; Mon, 15 Jan 2007 07:12:24 +0100 Received: from ppp14-213.lns2.syd7.internode.on.net (HELO rosella) ([59.167.14.213]) by ipmail02.adl2.internode.on.net with ESMTP; 15 Jan 2007 16:42:04 +1030 X-IronPort-AV: i="4.13,186,1167571800"; d="scan'208"; a="71627374:sNHT9667340018" Subject: Re: [Caml-list] Ocaml compiler features From: skaller To: Jon Harrop Cc: caml-list@yquem.inria.fr In-Reply-To: <200701150055.56886.jon@ffconsultancy.com> References: <45A87011.8080203@gmail.com> <200701142049.57959.jon@ffconsultancy.com> <20070115003823.7cd377c8@localhost> <200701150055.56886.jon@ffconsultancy.com> Content-Type: text/plain; charset=utf-8 Date: Mon, 15 Jan 2007 17:12:00 +1100 Message-Id: <1168841520.20477.66.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 8bit X-Miltered: at discorde with ID 45AB1B47.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 compiler:01 haskell:01 overloading:01 optimise:01 ocaml:01 trivial:01 pointer:01 pointer:01 mutable:01 haskell:01 semantics:01 exert:98 sourceforge:01 wrote:01 On Mon, 2007-01-15 at 00:55 +0000, Jon Harrop wrote: > On Sunday 14 January 2007 23:38, Gabriel Kerneis wrote: > > Le Sun, 14 Jan 2007 20:49:57 +0000, Jon Harrop > > a écrit : > > > Playing with Haskell and F# has opened my eyes a bit. F#'s operator > > > overloading and active patterns will make my code much nicer. Being > > > lazier can simplify things until you have to optimise, in which case > > > it suddenly becomes really complicated and error prone. > > > > What do you mean exactly in this last sentence ? I agree OCaml should > > evolve but what kind of "laziness" are you referring to ? > > Lazy (as opposed to eager) computation. OCaml is very eager. Using laziness > more can speed things up in some simple cases, e.g. nested maps and folds. This is not clear. Laziness can be very fast if well optimised, but optimisation is hard in general. The trivial case of nested maps and folds can be optimised by hand in Ocaml. It also isn't really true Ocaml is 'eager' in 'general'. Almost all constructions in all languages are in fact lazy: indeed procedural/imperative programming is ultimately lazy. A simple example: Ocaml match is lazy: match x with | true -> t | false -> f evaluates t or f lazily .. in general this is obviously necessary since any pattern variables (not exhibited in this case) are not known until the match is done. At best you can say function application in Ocaml is eager, and even that isn't true: wherever you use a reference, you're passing a pointer, and that's lazy evaluation, until you 'eagerify' it by dereferencing the pointer. Similarly when you pass a mutable data structure as an argument, evaluation is actually lazy .. operations on it are done *inside* the function body. So actually, in an imperative language like Ocaml, there is no real need for lazy evaluation of function arguments .. there is already plenty of control over evaluation time. The main downside is that the programmer needs to exert this control manually .. and that is also the main upside, compared to say Haskell, where you really don't know how good a job the optimiser is doing precisely because of the lazy semantics. -- John Skaller Felix, successor to C++: http://felix.sf.net