Re: Paris write-up

On 5 Dec 2005, at 09:56, James Strachan wrote:

>> I think that in both a script and a class vanilla names should be  
>> resolved at run time via the metaclass which will throw an  
>> exception if the name cannot be resolved.
>
> Sure.
>
> The issue is which class is responsible for resolving vanilla  
> names. In Java that's the outer class. I want to keep it that way  
> for Closures. I keep saying for closures its only the outer class  
> which should be used to resolve names - that's what closures are -  
> their vanilla names are bound, always, to the outer lexical scope.  
> Any other concept like dynamic vanilla name resolution is not a  
> closure. Now I'm not saying we can't support other ideas and  
> concepts; its just they are not closures.
>
> For markup we tend to want the builder to resolve names - hence the  
> reason I've separated the two concepts; a Closure *means* its names  
> are resolved to its lexical scope (not some other objects at  
> runtime) - that's what being a closure means. Markup is quite  
> different though and I'm more than happy to discuss different name  
> resolution mechanisms for Markup; but I see no reason yet to break  
> closures.
>
> i.e. my one constraint is if we introduce a new name resolution  
> mechanism like Markup it must be in a different lexical syntax.  
> Closures should be included in the language and a closure means  
> names are resolved on the outer class for non-local variables.

So do I understand this correctly?

You are saying that you agree the the compiler should let the  
metaclass should always be allowed to try and assign meaning to a  
vanilla name? (leaving aside for the moment the issue of which  
metaclass decides).

That is to say that if the compiler cannot resolve the name  
statically then it should leave it to the metaclass to resolve the  
name rather than to rise a compile time error?

John Wilson
The Wilson Partnership
http://www.wilson.co.uk