Tony Garnock-Jones wrote:
> Andreas Raab wrote:
>> This of course gets more interesting when you need more than single
>> parametrized method but the above illustrates the basic idea.
> 
> The other interesting part is the scoping of free identifiers within
> methods in the literal-object. Does a literal-object close over its
> environment like a block? Like a closure? Not at all? How are
> literal-objects initialized? Do they have instance variables?
> 
> There are *lots* of interesting variations in exactly *how* to treat
> free identifiers...

Actually I don't think so. Just be willing to make a few well-defined 
tradeoffs. Like: No accesses to the enclosing iVar scope. Send messages. 
For sending message we introduce an "outer" keyword just like we have 
"super" today. So you may have something like here:

Morph>>makeMorphWithDefaultBounds: defaultBounds
   ^def Morph [
	resetBounds [
	    bounds := defaultBounds expandBy: outer borderWidth.
	]
    ]

This is perfectly well-defined as far as the relationship between the 
inner and the outer iVar scope is concerned (e.g., no access to the 
outer scope). For the closure environment provided for the definition, 
I'd grant access to that (defaultBounds in the above) but without 
disambiguating shadowed variables (tough luck, rename the temp/arg if 
there is a conflict).

Seems pretty simple, obvious, and well-defined to me. (and yes, this is 
not the first time I've been thinking about this issue ;-)

> The whole idea is, I think, a good one - blocks themselves (well, more
> properly, closures) become special-cased syntactic sugar:

Exactly. It took me about ten years to grasp that methods are 
conceptually classes with the temps being the iVars of those classes and 
the contexts being their instances.

> [:a | a + 1] ===>
> 
> def Block [
>   value: a [
>     ^ a + 1
>   ]
> ]
> 
> 
> 
> It also introduces the thorny notion of naming partial continuations.
> (As in, which continuation does ^ throw to?)

Same as today. The difference between block and method is arbitrary 
(always has been) and I'd go so far as to say: "a method is a block you 
can return to", e.g., make the "returnability" part of what defines a 
method. Practically, this always has been true just "the other way 
around", e.g., if you had a block that you wanted to be able to return 
to, you'd have to make this block into a method.

Cheers,
   - Andreas