Can anyone justify closure treatment in self? It would seem to be
more in the spirit of self to merge closures with methods and perform
a purely dynamic message lookup, that is search block
locals/parameters, then follow parent slots (outer closures - and now
deprecated 'methods'). This would have an interesting side effect of
erasing the difference between closures, methods and objects - any of
these could be stuck into a slot and sent at least a 'value' message.
A method implementation would become therefore just another object
(with local, parameter and parent slots) which is sent a 'value'
message by default, but can accept other messages!
Then it is up to the programmer to decide whether to write
a 'block' inside a 'method' (an anonymous closure), create a method
(a named closure) or send messages to object or methods (that are
also objects) interchangeably.
As for the non-local return out of closures, is there a really good
reason for it? Why not return to the outer scope (other than perhaps
a clumsier syntax)?
Forgive my possible stupidity - I am stuck in x86 world and haven't
been able to explore self personally. I am amazed at the clarity of
reasoning behind self, with this minor exception. Perhaps someone
can clarify this.