Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!news.hal.COM!decwrl!netcomsv!netcom.com!mmk
From: mmk@netcom.com (Mark Kunichika)
Subject: Re: Block = Closure (NOT!)
Message-ID: <mmkCyD2o2.4ry@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <30elt3$fgs@beta.qmw.ac.uk> <38g02f$hmm@rzsun02.rrz.uni-hamburg.de> <38jspl$5jh@columba.udac.uu.se> <38m7f9$9h2@ns.oar.net>
Date: Fri, 28 Oct 1994 02:24:02 GMT
Lines: 54

In article <38m7f9$9h2@ns.oar.net>,  <drr@terrapin.raleigh.com> wrote:
[snip]
>However, Messages are useless as an anonymous lambda, which I suppose Blocks
>do approximate. Blocks have other unfortunate problems because they are
>tied to the MethodContext of there definition. PP, I don't know about, but
>I suppose that someone out there does. eg (in Digitalk):
>
>    Smalltalk at: #FactorialFunction put: nil.
>    Smalltalk at: #FactorialFunction put: [ :n |
>        n = 0
>            ifTrue: [ 1 ]
>            ifFalse: [ n * FactorialFunction value: (n - 1) ]]
>
>has problems because of the recursive "call", pretty much in any version
>of ST. (I can actually think of ways to fix this, but that's beside the point)
[snip]

Hmm. This seems to work in PPST 4.1, as I thought it would. The only
problems (well, the ones that make my head hurt) I run into with
block closures is in using blocks that refer to variables in the
defining method rather than true locals or args, and only then
when I use or further process them (by using them in other blocks)
before returning from the defining method. That is:

on Integer:


| multiplier resultBlocks |
self > 0 ifTrue: [self error: 'oops'].
resultBlocks := OrderedCollection new.
multiplier := 1.
5 timesRepeat: [
	resultBlocks addLast: [:multiplicand | multiplicand * multiplier].
	multiplier := multipler + 1
].
(resultBlocks at: 3) value: 1


Instead of 3, the last statement's value is 6.

OK: This example is starting to look more stupidly embarrassing the more
I look at it and I have to admit having to try hard to make up an example
that didn't work. Anyway, in this case, all the result blocks have the
same behavior, since they all refer to the same "multiplier", whose
value is actually "1 + self". At any rate, I remember running into this
problem in a less obvious instance.

-mark
	
-- 
Mark Kunichika                                            mmk@netcom.com
Senior Consultant                                         (817) 967-6293
SABRE Decision Technologies                               (214) 380-8540
American Airlines         
      All opinions expressed here are those of the author and not of AA
