Re: [Caml-list] Re: generic programming

[John Max Skaller <skaller@ozemail.com.au>]

Chris Hecker wrote:

>
> Both of these are examples of "push versus pull" interfaces, and pull 
> just seems to work better.  Having data pushed at you means you often 
> end up buffering it on your end to manage your flow control anyway 
> unless you're just doing some trivial processing. 

This was once explained to me really well, I can't hope to give as good 
an explanation as I was given,
but I'll try: the reason 'pull' is better is that the natural place to 
put your state data is
'on the stack' and the most important case of this data is the program 
counter.

Put another way, your location in the code is the best way to encode the 
configuration
of your state data, which has something to do with the naturalness of 
block structured
programming: when you are 'here' in the code, 'these' variables are visible
and contain the state.

> I'm not saying that callback/push interfaces are always bad, 

What Francois Pottier said is correct, IMHO: callbacks are best in 
simple cases,
in particular, when there is NO state, using them clearly makes the 
simple structure
of your code evident in the syntax.

Callbacks are *also* probably best when the problem is extremely
complex.

But 'pull' interfaces shine when there is a natural heirarchical
decomposition which can be readily represented by putting
all your state data on the machine stack, and encoding
the 'variant tag' of the union of all stack states in the
natural place -- the program counter.

So: when you don't need state data, the stack doesn't help,
you might as well use a callback. And when the problem
is really complex, you might as well put all your data
into an object, and drive the system as a state machine:
this is better than mixing up the explicit and implicit
state in an arbitrary way (some on the stack, some
in a state object ..) In between, there is a large class
of tree structured problems that admit a clean solution using
subroutines and local variables.

Classic example: recursive descent parser.

Classic counter example: Earley parser (needs frames threaded
in two distinct ways, to allow one to go back and try again
after success as well as failure).

heh. It is interesting that Ocaml experts are arguing
for functional iterators -- which in fact amount
to 'goto' programming, whilst the 'pull' interface
is the essence of functional decomposition :-)
The power and utility of the machine stack is hard
to deny -- it is important enough that hardward provides it :-)

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners