Re: [Caml-list] The Implicit Accumulator: a design pattern using optional arguments

[Thomas Fischbacher <tf@functionality.de>]

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