mike_ekim at yahoo.com
Fri Nov 21 05:28:53 UTC 2003
--- In self-interest at yahoogroups.com, Jecel Assumpcao Jr <jecel at m...>
> On Thursday 20 November 2003 07:17, Mike Austin wrote:
> > --- In self-interest at yahoogroups.com, Jecel Assumpcao Jr
<jecel at m...>
> > wrote:
> > > But what is "their enclosing environment"?
> > B) The activation object, or method-instance for another term
> > > And who are we talking about in "their proto (parent, actually)
> > to"?
> > > 1) The block literal object?
> > > 2) The result of referencing 1 with a "push literal"?
> > > 3) The block closure resulting from sending 'value' to 2?
> > 1) The block literal object
> Now we have a problem. Unfortunately, B doesn't yet exist when the
> parser is creating 1 from the source text. It is likely that you
> different definitions from what I am used to, so I will try to be
> clearer below.
> > Although Io handles locals a bit different, it is essentially the
> > same idea when I do this:
> > myObject = Object clone do (
> > ` add = method ( n,
> > ` ` return block( x, return n + x )
> The expression "block(...)" is what I called 1 above.
> > ` )
> > )
> > a = myObject add( 10 )
> > b = myObject add( 20 )
> a and b are two instances of what I called 2 above.
> > write( a( 10 ), "\n" )
> > write( b( 10 ), "\n" )
> a( 10 ) and b( 10 ) are two instances of what I called 3 above.
> > > io closure_test.io
> > 20
> > 30
> > The returned block's proto is set to the new "Locals" instance
> > is created when calling add. It works simply, and beautifully.
> Ok, so you set the proto of 2 to B and then 3 gets to inherit it. I
> haven't paid attention to such details in Io, however, and would be
> happy for you or Steve to correct me.
> It certainly does work, but I wouldn't call it simple. Since Self
> doesn't allow non-lifo blocks, I'll rewrite your example in
> MyObject>>add: n
> ^ [:x | x + n]
> a := myObject add: 10.
> b := myObject add: 20.
> Transcript show: (a value: 10).
> Transcript show: (b value: 10).
> I will agree that if you don't care about the multiple steps and
> needed to make this work, it looks simple enough. Explaining how to
> blocks isn't a problem for me, but explaining how they get their
> done is.
I believe the implementation of closures can be fairly simple in a
dynamic language. As for the efficiency - handing stack allocated
locals and frames for example, I'm aware that this can get much more
complex. Actually, I feel a bit of deja vu here, must of talked
about it in the past :)
More information about the Self-interest