Thoughts on laziness (long)

[Jeffrey Straszhiem]

On Fri, Oct 20, 2000 at 09:40:24AM +0200, Ulf Wiger wrote:

> My point is that you could well claim that the one impure feature of
> Erlang's is message passing. Ets tables bring nothing more to the
> table than what could be done using "classic" Erlang - it just does
> it faster.

True.  Actually I had assumed, without looking at the implementation,
that ets tables were indeed processes as you describe.  I guess I
learn something new everyday. :)

>> One thing your comparison did not point out is this data is only
>> relevant in cases where you use the data in a single-threaded
>> manner.  By "single-threaded" here I don't mean to imply
>> concurrency, but instead threads of data flow.  Here is an example:

> Ehmm, I'm not too sure about this. If you have the case of a single
> process updating a private data structure, then you can do well with
> a functional data structure on the process's own heap, but as soon
> as you want to support concurrency, you need to place the data
> structure in a server process; then it's entirely up to that process
> to decide which granularity of concurrency you want. In order to
> support safe updates on ets tables, you'd funnel all updates through
> a server process, while atomic reads might go directly agains the
> ets table (for the functional structure, all operations must go
> through the same process).

Again true.  In many ways Erlang server processes can end up looking
alot like objects with state, and not so much like "processes" at all.
I think your ets as a server example proves this point.  However,
within an implementation of a server process there may arise a case
where a complex computation might need to be performed.  If this sort
of computation is the kind that would benefit from laziness then it
would pay off.

That being said, I'm not sure how common the payoff would be.  It is
certainly possible that laziness in Erlang would not be worth its
cost.  On the other hand, simply providing 'suspend' and 'force'
operators to the language shouldn't be too difficult.  Newcomers to
the language could produce plenty of code without them -- I really
imagine them used by experts to build data structure modules -- so
they need not impede the simplicity of learning.

Anyhow, surely everyone will agree that it is worth more thought.

-- Jeffrey Straszheim              |  A sufficiently advanced
-- Systems Engineer, Programmer    |  regular expression is
-- http://www.shadow.net/~stimuli  |  indistinguishable from
-- stimuli AT shadow DOT net       |  magic