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 EF0D8BC6B for ; Wed, 27 Jun 2007 21:26:38 +0200 (CEST) Received: from smtp28.orange.fr (smtp28.orange.fr [80.12.242.101]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5RJQcOJ024225 for ; Wed, 27 Jun 2007 21:26:38 +0200 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2827.orange.fr (SMTP Server) with ESMTP id 4EF7A700008F for ; Wed, 27 Jun 2007 21:26:37 +0200 (CEST) Received: from [192.168.1.162] (ALagny-153-1-98-23.w90-3.abo.wanadoo.fr [90.3.145.23]) by mwinf2827.orange.fr (SMTP Server) with ESMTP id F2F63700008E for ; Wed, 27 Jun 2007 21:26:36 +0200 (CEST) X-ME-UUID: 20070627192636995.F2F63700008E@mwinf2827.orange.fr Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <468292AA.3040009@functionality.de> References: <200706271314.35134.jon@ffconsultancy.com> <1A1D6F56-B3DB-4552-969C-9859482175AC@lrde.epita.fr> <46826C69.5060802@functionality.de> <468292AA.3040009@functionality.de> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <85519A86-E765-4C3A-B292-2F9B150913AC@lrde.epita.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Qu=F4c_Peyrot?= Subject: Re: [Caml-list] The Implicit Accumulator: a design pattern using optional arguments Date: Wed, 27 Jun 2007 21:26:35 +0200 To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.752.2) X-Miltered: at concorde with ID 4682B9EE.005 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; lrde:01 allocating:01 ocaml:01 hash:01 memoizing:01 defines:01 memoization:01 memoizing:01 memoization:01 memoized:01 lexically:01 ocaml:01 hash:01 memoized:01 computations:01 On Jun 27, 2007, at 6:39 PM, Thomas Fischbacher wrote: > > Qu=F4c Peyrot wrote: > >>> There are many many way more advanced tricks one would want to play >>> with the idea of "allocating buffers at the appropriate time". For >>> example, if this were LISP, one could often use dynamically =20 >>> scoped (in >>> the sense of (declare (dynamic-extent buffer-stack))) contextual >>> variables for great benefit (and these gory details often can =20 >>> also be >>> hidden quite conveniently under a few (maybe even in-place macrolet) >>> macros...), but unfortunately, OCaml does not support anything like >>> that. Of course, re-entrantness of your code may always become an >>> issue if you move buffers to higher scopes. >> I didn't get that part, but I'm not familiar with Lisp. > > One example: what you can do quite easily in LISP is to introduce > a global lookup thingy MEMOIZATIONS (say, a list of hash tables > or something like that) and define macros WITH-LOCAL-MEMORY and > MEMOIZING where WITH-LOCAL-MEMORY defines a new dynamic > memoization scope, and MEMOIZING wraps up a few functions in such > a way that they use memoization. Result: we can have both > memoization on functions as well as defined behaviour with respect > to when memoized values are being forgotten again (namely, when > we are finished with the evaluation of the form > > (WITH-LOCAL-MEMORY ...)). > > Note that functions dynamically called from functions lexically scoped > inside this construct will ALSO use the same local memoization table! > In other words, when control flow exits the WITH-LOCAL-MEMORY block > (in whatever way it does so), our memoizing information is returned to > precisely the state it was in before we entered that block. That is > the magic of dynamic scoping. I'm not sure I understand why we can't do it in ocaml, but I would probably need to try to implement it to see why. I mean if we implement something along the lines: let memo f =3D let hash =3D ... then can't we have the same feature using "let in" ? let memoized_f =3D memo f in let memoized_f =3D memo f in (* when we leave this scope, we should get back the first table *) >> I mean, for someone like me, with quite some experience in the asm/=20= >> c/c ++ world (i.e. a garbage collector-less world) but not much in =20= >> other languages, it's easy to naively think of a garbage =20 >> collector as a fancy feature to prevent from having to call "free/=20= >> delete". But I'm starting to realize there is a whole new set of =20 >> powerful design patterns which come along. It has been said =20 >> multiple times on this mailing list, but I think we really miss a =20= >> book about these design patterns and optimization tricks often =20 >> specific to a given (or a set of) feature (functional, lazy =20 >> computations, garbage collector...). [...] > With this, I suppose, a proper book on both "functional optimization > strategies" and "ideas that help you to overcome mental barriers with > respect to what's possible when one can shape the language" would be > useful, not so much to "teach specific patterns", but to teach people > how to overcome their mental blockades and learn how to use their > phantasy to do marvelous things by shaping language. In the > Permaculture community, there is this proverb that "yield is > limited only by imagination". I think this holds just as much for > functional and in particular metalinguistic programming. I wanted to prevent from reducing my comment to the "functional" part. The design patterns discussed in this thread has more to do with ocaml itself (or the garbage collector for my example). I've seen plenty of =20= tutorials and articles about functional languages but they often expose the same things and lack (from my point of view again, please keep in mind that runtime/memory efficiency is important to me) on the efficiency =20 side (especially the memory one, often ignoring as well the big runtime =20 hit you can have due to the allocations). Writing concise and elegant code is very important to me, really. I hate dirty ugly code, but I'm not willing to sacrifice the efficiency. =20 That's why I really like OCaml, it is very powerful but allows us to efficient =20 code... as long as you actually do understand how the compiler is going to process your code. And that's the book I wish I could have. We can call that design pattern or industry best practices. I just want to be =20 able to write real-life code (and not necessarily scientific-oriented code, =20 sorry Jon Harrop ;) ) without having to re-discover all these best practices (which might be very natural for someone with a deeper understanding of all the different features a specific language provides). I don't =20 think the only subtle part of OCaml is the fact that it is a functional =20 language. There is really more to it, IMHO. > (I have been planning for years to eventually write up some > lengthier introductory text on metalinguistic techniques, but so > far only managed to write a few articles and give some short courses > on the subject...) Keep us posted ;) >> I find it ironical that high-level languages (such as ocaml) are =20 >> intended (of course that's my interpretation of it) to hide low-=20 >> level details and give you more expressiveness in your code, =20 >> which should naively make you more productive, and make it easier =20= >> to program something. But requires therefore tons of new =20 >> knowledges and deep understanding of advanced concepts to be able =20= >> to actually code efficient (runtime and memory-wise) code. > > Languages such as OCaml are not "intended to hide low-level details". Sorry, I'm not really good with words, I indeed wanted to talk about (2) > > Rather, there are (at least) two very different notions of =20 > "programming" > around: > > (1) Putting information into a mechanically behaving system in order > to get some desired behaviour. (This is what asm/C/C++ is about, > but actually, this even is a much broader notion that also =20 > includes > e.g. this: http://amasci.com/amateur/mirror.html) > > (2) Formalizing some "mental process" in such a way that one can > then use stringent reasoning to analyze its properties. (This is > what, in essence, functional programming is about.) > > > Evidently, the more advanced you get, the more important the second > point of view becomes. (2) is very important to me, but as said earlier, I often found while =20= reading articles (functional programming) that highly category-2 oriented people tend not to care at all (or barely) about real-life runtime of the =20 program. Writing correct code is not good enough, I need to be able to execute it within my life-time (I know, I'm a bit provocative here ;) ) We often oppose category-2 oriented people with category-1 oriented =20 people. I think we can meet somewhere in a middle, and the book we talked about would certainly help. But yes, I agree that, sometimes, the design pattern is here to solve =20= a problem the language itself should solve, but that's not always the case. --=20 Best Regards, Qu=F4c