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 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 77A3EBC6B for ; Thu, 28 Jun 2007 13:39:18 +0200 (CEST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5SBdI0v005311 for ; Thu, 28 Jun 2007 13:39:18 +0200 Received: from [141.84.136.30] (helo=[152.78.96.56]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1I3sKk3UHX-0006PG; Thu, 28 Jun 2007 13:38:47 +0200 Message-ID: <46839DD8.7040200@functionality.de> Date: Thu, 28 Jun 2007 12:39:04 +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: =?ISO-8859-1?Q?Qu=F4c_Peyrot?= 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> <1A1D6F56-B3DB-4552-969C-9859482175AC@lrde.epita.fr> <46826C69.5060802@functionality.de> <468292AA.3040009@functionality.de> <85519A86-E765-4C3A-B292-2F9B150913AC@lrde.epita.fr> In-Reply-To: <85519A86-E765-4C3A-B292-2F9B150913AC@lrde.epita.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V01U2FsdGVkX1/uca//+uLw91n65HczRRPeVXeNdEFnd9ZxwzZ TTmzOm393wXAv/mUKXVU1M/y5Brqlmj+kaNdZDlwZC8y5FbjQX Yg5cetmEDwjsX4iKZkieA== X-Miltered: at concorde with ID 46839DE6.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; memoized:01 memoized:01 stack:01 vectors:01 stack:01 computations:01 ocaml:01 runtime:01 runtime:01 allocations:01 malloc:01 formalizing:01 evidently:01 stays:98 lexical:01 Quôc Peyrot wrote: > let memoized_f = memo f in > let memoized_f = memo f in > (* when we leave this scope, we should get back the first table *) Yes, but this only concerns the LEXICAL scope (i.e. as long as execution flow stays within that piece of code that is written dow as the "in" body of this "let in". I am talking about DYNAMICAL scope, i.e. something visible also to functions which I call from within there, which can be defined in a completely different place in the code. Let's take some animated 3d application. You may want to introduce a dynamically scoped notion of, say, "pre-allocated stack of buffers for position vectors which behaves like a C stack with respect to functions temporarily using this for computations", so that all the functions that call one another during rendering of a frame may use that very same stack in an orderly fashion (with scoping behaviour just as the C stack). Still, the existence and visibility of this stack is confined to some "render-animation" function. > 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 > 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 side > (especially the memory one, often ignoring as well the big runtime hit you > can have due to the allocations). The issue with functional programming is that using dynamic memory management (which is very complicated under the hood) is very easy for the programmer, and hence quite seductive - even in situations where for performance reasons, one should not do so. With C/C++, using dynamic memory management is considerable effort (all these calls to malloc()/free()), so people are naturally more inclined to avoid it wherever it is unnecessary. But also here, it still is very complicated things going on under the hood. (Concerning the "but I at least get guarantees on execution times": how does one know how long a free() is going to take, and in what sense is this then better than temporarily disabling GC until we reach a point where we can spend some time on it?) >> Rather, there are (at least) two very different notions of "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 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. > We often oppose category-2 oriented people with category-1 oriented > people. > I think we can meet somewhere in a middle, and the book we talked about > would certainly help. Well, as these are really basically unrelated notions of "programming", there is little that speaks against approaches that include ideas and heed aspects of programming(1) as well as programming(2). It is easy to get into the pitfall os supposing that one could only have either the one or the other. -- best regards, Thomas Fischbacher tf@functionality.de