Re: [Ocaml-lib-devel] Enums vs. Streams

[skaller <sk...@us...>]

On Tue, 2004-05-11 at 23:57, John Goerzen wrote:
> On Tue, May 11, 2004 at 11:36:31PM +1000, skaller wrote:
> > one more thought. Consider the question:
> > 
> > What does the laziness in Enum's buy you?
> 
> I'm still not quite sure I understand why Enum has laziness but streams
> don't.
> 
> If you do a stream of a function, the functio ndoesn't evaluate anything
> until next() is called on the stream to retrieve the next valie.

All good programmers and streams are intrinsically lazy :)

The problem here is just when 'next' can be called.
That's really the bottom line.

If the enum uses buffering .. and they must, that's
the whole point of the design, to use 'an efficient
internal data structure' .. then 'next' is going
to be called at unpredictable times.

At least *some* indeterminacy is *required*
to give the implementor freedom to arrange
the buffering.

As an example, two 'stacked maps' might be
implemented by:

	let b = map f a in
	let c = map g b in

or by:

	let c = map (g * f) a in

The sequence of calls in the first case are:

	f f f f f f f f f 
	g g g g g g g g g

but in the second case are

	f g f g f g f g f
	g f g f g f g f g


and I'm sure you can imagine functions 'f' and 'g'
for which this makes a difference.

This example is only meant to be an illustration
of how an implementation detail can make a huge
difference in stateful programming.

The contradiction in the current design is that
it tries to be 'purely functional' but at the
same time also handle 'input iterators' in a seamless
manner. To make this work, some constraints on
both the client and Enum package are needed
to ensure semantics are maintained.

-- 
John Skaller, mailto:sk...@us...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net