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

[Thomas Fischbacher <tf@functionality.de>]

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