Lazy evaluation?

I fully realize that this is probably not the smartest question. Seemed a bit advanced for the beginners list though.

I've been studying procedural/fractal terrain. It would seem that much of it hinges on "lazy evaluation," which is a term some Haskell hackers I knew threw around. The gist I got was that lazy evaluation involved two things, referential transparency and evaluation avoidance.

Since Smalltalk is late bound, I think I can avoid evaluating expressions as long as I like with closures... but since it's mutable state all the way down, I wonder about the referential transparency part. I mean, Turing completeness suggests that it's doable, I'm just wondering how painful it would be.

Guessing someone here will have a better understanding of the whole lazy eval business, and I'm particularly interested in seeing implementations that use it.

Hi Casey,

I would give an initial pointer to this article on the VPRI website, which apparently even has an implementation: http://www.vpri.org/pdf/m2009006_lazylist.pdf

It may betray a misunderstanding of lazy evalutation on my part, but the chapter on streams in SICP might also provide some interesting reading.

I hope that this is helpful to you,
Jeff G.

That paper will mention the basic technique of lazy evaluation in a
strict language, which is just wrapping an expression up in a block:

    [self myExpression: param and: thatParam]

Now you can pass that block - thunk - around, and evaluate it only
when required.

Watch in that paper how the tail of a list is a block that, when
evaluated, yields another element in the list... and leaves the thunk
as the tail.

frank

On 9 July 2011 17:41, Jeff G <[hidden email]> wrote:

>>>>> "Frank" == Frank Shearar <[hidden email]> writes:

Frank> That paper will mention the basic technique of lazy evaluation in a
Frank> strict language, which is just wrapping an expression up in a block:

Frank>     [self myExpression: param and: thatParam]

Frank> Now you can pass that block - thunk - around, and evaluate it only
Frank> when required.

There's also the whole "futures" thing.  I think that's even close to
being in Squeak core.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

On 9 July 2011 18:44, Randal L. Schwartz <[hidden email]> wrote:
That's already in there - look at FutureMaker and, more importantly, FutureNode.

frank

> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.posterous.com/ for Smalltalk discussion
>

On 9 July 2011 18:52, Frank Shearar <[hidden email]> wrote:
And before I forget, the Xtreams stream framework has a distinctly
lazy feel to it.

frank

>>>>> "Randal" == Randal L Schwartz <[hidden email]> writes:

>>>>> "Frank" == Frank Shearar <[hidden email]> writes:
Frank> That paper will mention the basic technique of lazy evaluation in a
Frank> strict language, which is just wrapping an expression up in a block:

Frank> [self myExpression: param and: thatParam]

Frank> Now you can pass that block - thunk - around, and evaluate it only
Frank> when required.

Randal> There's also the whole "futures" thing.  I think that's even close to
Randal> being in Squeak core.

Not even "close to".  See "Promise" class in Squeak 4.2.

1 future + 1 "becomes 2 when sent #value".

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion