Re: [groovy-dev] making the bytecode generation more understandable

On 7 Oct 2004, at 09:29, John Rose wrote:
> On Oct 7, 2004, at 0:35, jastrachan@... wrote:
>> Incidentally one of the main drivers of making the bytecode 
>> generation more understandable is to be able to really tune things. 
>> e.g. if you use static typing (or the compiler can easily deduce the 
>> type of an expression) we really should be able to generate bytecode 
>> which is as efficient as Java. As well as being a completely dynamic 
>> scripting language, I'd also like to use Groovy as a drop in 
>> replacement for Java for high performance coding as well.
>
> To be able to have some symbols refer statically to classes and others 
> refer dynamically to (say) script environment variables or global 
> functions and still others refer dynamically to markup and yet still 
> others refer statically to local variables in enclosing scopes 
> means... we really need to get our scoping story straightened out.

Agreed.

> I know it will break some things, but I would really like to simplify 
> the scoping story by having plain, vanilla names be almost always 
> lexically, statically scoped.  Two exceptions:  1. As a last resort 
> when there is no compile-time binding available, we obviously punt to 
> the runtime.  2. Specifically and only in groovy markup, markup names 
> will talk to the builder, not the compiler's symbol table.  This 
> requires a more slightly explicit syntactic cue to distinguish the 
> scopes where groovy markup is in play.  The {{ mark we discussed once 
> is such a cue.

Agreed.

> Then the scoping design problem breaks into two parts:  What the 
> compiler knows at compile time about vanilla names, including 
> quasi-typed local variables, and classes and packages on the 
> compiler's classpath.  The other part covers non-vanilla, qualified 
> names, most of which are governed by exceedingly dynamic rules which 
> compute their meanings at runtime (while leaving some room for static 
> optimizations).
>
> (Certain name qualifiers, like 'this.' or 'java.lang.' if we support 
> packages, can have some static smarts in them, allowing the compiler 
> to statically bind some of the names that they qualify.  Such 
> qualifiers act like modules, really.  Vanilla names could be regarded 
> as references to some sort of unnamed module.  But if 'x' is untyped, 
> the qualified 'x.y' must punt immediately to the runtime.)
>
> On balance, I feel it is "beyond groovy" (dare I say, "techno punk"?) 
> to have a simple identifier perform multiple runtime lookups to find 
> its meaning.  (There's also the scary throw/catch backtracking in 
> Closure.java.)  A programmer has got to be able to trust a simple 
> identifier to have a fixed meaning, or else all the program's meaning 
> is up for grabs until runtime.  I'm saying this with some diffidence 
> (see my facial expression?  ), because I know there is lots of 
> example code which does wild and fancy things with simple identifiers. 
>  Those examples, however, are the lurking places of bad implementation 
> bugs and design contradictions.
>
> Before I bid you a cheery good night, here is a good essay about 
> backtracking in the creative process.  The quotes at the end are scary 
> but good:
>   http://www.uiweb.com/issues/issue08.htm
>
> And, as a gratuitous bonus, here is a superb essay a 
> philosopher/hacker friend pointed out:
>   http://www.paulgraham.com/hp.html
>
> In Paul Graham's specific terms, Groovy is groovy because it's made by 
> makers.

:)

Totally agree.

Hopefully once we've got the naming scope stuff sorted out, it won't 
have a drastic change - the kinds of scripts we've been writing in 
Groovy over the last year should still work - its mostly edge cases and 
the implementation that'll change. GroovyMarkup though needs to change 
I think; as its a bit of a hack right now. However the {{ (or whatever 
token we choose) is a fairly minor change.

James
-------
http://radio.weblogs.com/0112098/