Closure/method discrepancy...

[victor_yurkovsky]

Jecel, thanks for your answers.

Let's postpone the activation record discussion (I am very curious 
about the double-cloning and istalling as own parent thought..) as an 
implementation issue.

Now, the lifespan of a block, as you pointed out, is limited to the 
lexically enclosing method.  As an implementer, I can understand the 
desire to keep activation records on the stack for efficiency, and 
that implies that the record cannot survive the stack frame of the 
method.  However, it does preclude me from passing a block out of a 
method and sticking it into a slot of a more permanent object.  That 
seems like a deficiency as I often find myself (in smalltalk) in 
situations where I really wish to replace a method with another one 
after the state of the object changes (instead of a slower 
conditional).  Am I missing something here - is there another 
mechanism in self to replace the contents of a slot with another 
(precompiled or dynamically generated) entity?  I guess you can 
replace the contents of a slot with anything you want, so that would 
be the way to do it.   It just really yanks me that the creation of a 
block and a method is not syntactically identical.  

As for scoping, do I really understand it correctly that a block 
statically binds to objects of the enclosing method at compile time?  
It would be just so much cleaner to bind at run time... Ah...  It 
seems like there are at least two distinct uses of a block: 
partitioning a method (requires lexical access to method slots), the 
other a generic submethod to be passed around (such as a sort block), 
requires dynamic access to run-time method's slots that can be faked 
by passing parameters.  Perhaps these should be treated as different 
animals, or the programer be given the choice of lexical/dynamic 
binding of a block?  Of course, dynamic binding works in both cases 
as the partition-type block is executed within the same method it was 
compiled in...

To clarify my seminonsensical last message, it seems that there is a 
more generic way to implement an oo environment within which self can 
be instantiated, just like smalltalk can be instantiated in self...  
The object with slots and data/code (data of course is code 
interpreted by some program or hardware...) seems like about as low 
as I would be willing to go.  From there on, it is mostly the 
question of when to bind.  Bind everything at compile time and you 
have Forth.  Bind objects at compile time and messages at runtime, 
and you have Smalltalk.  Bind everything at runtime, and what do you 
have?

You are totally right about my missing out on the assignment issues.  
The big problem here is name binding again - do names bind the slots 
or objects inside those slots?  Is a slot, perhaps, an object capable 
of assignment? I have to think about it some more as I am quickly 
approaching middle age and my mind is not working as well as it did 
(or at least as I remember it doing).