Re: [groovy-jsr] name resolution rules somewhere? (dynamic vs. static lookups)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] name resolution rules somewhere? (dynamic vs. static lookups)

John Rose-2
On Oct 16, 2005, at 2:51, Nebojsa Vasiljevic wrote:

for example the vocubalary. I know John Rose does know what "markup 
scope" means, but different other people not. And each position should 
be available. And because these themes where last dscussed 9 months or 
more ago, it's good to see if the postion has changed somehwere. And we 
ave new members. Those where not at the last meeting, they don't know 
the direction.

I agree. We have to work more on documents, not only to discuss and code.

For instance, John Rose wrote a proposed solution for a set of issues. Let's try to make detailed description and put it on a Wiki page. If Jochen Theodorou suggests alternative solution, he with others who support this option should also make a detailed description. After that we will discuss what option is best trade off, and also discuss improvements in specific options. 

I just posted such a description here:

I suggest putting at least some of the rationale discussion into the page itself, or into sibling or child pages, as seems appropriate.

It would be great to move toward a condensed summary of scoping (and other big burning issues), with rationale and alternative discussion linked to the side.
(Feel free to move the initial rationale language into side pages, especially if you want to amend or extend the rationale text.)

My main thought about John W.'s suggestion of a separate (reverse) dynamic scoping pass is that it feels like two languages in uneasy coexistence.
I tried to address this concern in the wiki page by calling out the features of a helpful coexistence between static and dynamic scoping.
I think this is best done by keeping dynamic scoping from interfering with static scoping, by:
 (a) limiting the occasions for dynamic scoping
 (b) when dynamic scoping occurs, having it be fairly obvious (e.g., 'with', qualified names)
 (c) directing dynamic scoping requests to single objects, rather than trees of dynamic scopes with complicated precedence rules

I hope this helps.

-- John
Reply | Threaded
Open this post in threaded view
|

RE: [groovy-jsr] name resolution rules somewhere? (dynamic vs. static lookups)

Dierk König
Hi John,

thanks for assembling all this information on the page!

I'm not a language design expert and so I struggle with understanding
all implications your proposal has but it is anyway a good
overview.

cheers
Mittie

----
I just posted such a description here:
http://docs.codehaus.org/display/GroovyJSR/mostly+static+name+resolution

[..]
My main thought about John W.'s suggestion of a separate (reverse) dynamic
scoping pass is that it feels like two languages in uneasy coexistence.
I tried to address this concern in the wiki page by calling out the features
of a helpful coexistence between static and dynamic scoping.
I think this is best done by keeping dynamic scoping from interfering with
static scoping, by:
(a) limiting the occasions for dynamic scoping
(b) when dynamic scoping occurs, having it be fairly obvious (e.g., 'with',
qualified names)
(c) directing dynamic scoping requests to single objects, rather than trees
of dynamic scopes with complicated precedence rules

Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] name resolution rules somewhere? (dynamic vs. static lookups)

tugwilson
In reply to this post by John Rose-2

On 3 Nov 2005, at 08:02, John Rose wrote:

> I just posted such a description here:
> http://docs.codehaus.org/display/GroovyJSR/mostly+static+name 
> +resolution
>

The proposal appears to provide no way for a script to create a name  
in the Binding. Is this intentional or an oversight?


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


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] name resolution rules somewhere? (dynamic vs. static lookups)

John Rose-2
On Nov 3, 2005, at 3:28, John Wilson wrote:
On 3 Nov 2005, at 08:02, John Rose wrote:

I just posted such a description here:

The proposal appears to provide no way for a script to create a name in the Binding. Is this intentional or an oversight?

Bindings are not named in the proposal, because they are not part of the compile-time processing of the program.  But the relevant paragraph is here:
In particular, the compile-time environment for a script will often incorporate a single, unnamed dynamic import.  In such a script, simple names which do not reach a static declaration will be treated as untyped values to be retrieved from the script's container at runtime, via the TBD interface (an enclosing GroovyObject?).

As far as the compile-time nature of the language is concerned, if the special dynamic import is turned on in the compiler, any name unrecognized by the compiler needs to get punted from compile-time to run-time, and hooked up with the script's binding.  (Otherwise it's reportable as a typo., an error.)  The idea of a "dynamic import" applies to anything the language can do with an imported name:  get, set, call, etc.

So, yes, a script can create a new dynamic binding in its container simply by assigning to a new name.  From the language perspective, for a script to create a new variable by assigning a first value to it is equivalent to the variable pre-existing forever, with no initial value.

One of the "TBD" questions for me (in the paragraph quoted above) is whether to supply a more nuanced API for supplying run-time name bindings to scripts, which would take account of the "shape" of the name occurrence, as determined at compile time.  (E.g., distinguish method references from variable references from classes, so the binding could keep them separate if desired.)

My first question, though, is whether the accounting of "shapes" of references makes sense (and is helpful) for describing compile-time activities.  I'm interested to hear...

-- John

Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] name resolution rules somewhere? (dynamic vs. static lookups)

tugwilson

On 3 Nov 2005, at 19:57, John Rose wrote:

> My first question, though, is whether the accounting of "shapes" of  
> references makes sense (and is helpful) for describing compile-time  
> activities.  I'm interested to hear...
>


I found it rather difficult to follow.

 From what I can see you are proposing a very radical change to our  
existing system. I presume that calls to methods on would not go via  
the MetaClass of the current class?




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


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] name resolution rules somewhere? (dynamic vs. static lookups)

John Rose-2
On Nov 3, 2005, at 12:16, John Wilson wrote:
From what I can see you are proposing a very radical change to our existing system. I presume that calls to methods on would not go via the MetaClass of the current class?

The proposal says nothing about the implementation details of runtime method calls.
It states that they simulate analogous statically typed calls.
I don't think that requirement conflicts with the current technique of going via the MetaClass.

(Then again, the behavior of the MetaClass is not well specified yet either,
so it's hard to tell.  Maybe I'm missing some feature of the code that's
inconsistent with my proposal...)

I'm not sure how to take your "very radical change" comment.     
Probably the most radical part of what I'm doing is trying to write
a specification that makes sense as a language specification,
rather than a bug-for-bug-correct operational account of the
behavior of the current code.  As we've already seen, the
exercise of trying to do this can root out deficiencies in the
language implemented by the current code.  If that's radical,
so be it.  I don't see any other way to get to a useful spec.

-- John
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] name resolution rules somewhere? (dynamic vs. static lookups)

tugwilson

On 3 Nov 2005, at 22:51, John Rose wrote:

> The proposal says nothing about the implementation details of  
> runtime method calls.
> It states that they simulate analogous statically typed calls.
> I don't think that requirement conflicts with the current technique  
> of going via the MetaClass.
>

I think it does, John

The MetaClass is given a name and some parameters and decides what to  
do with these. We have control over the behaviour of the standard  
MetaClass so we could, in principle, implement whatever semantics we  
choose. However, Groovy allows the users to replace the MetaClass  
with whatever implementation they like (a custom MetaClass can be  
specified on a per class basis and, for classes which implement  
GroovyObject, on a per instance basis).

All we can control is the names which can be accepted and rejected by  
the compiler and the behaviour of the default MetaClass.

It is important that the compiler writers understand what they can  
and cannot do - they should not be permitted to "optimise" calls in a  
way in which changes the semantics of a program.



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


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] name resolution rules somewhere? (dynamic vs. static lookups)

Jochen Theodorou
In reply to this post by John Rose-2
John Rose schrieb:
[...]
> I just posted such a description here:
> http://docs.codehaus.org/display/GroovyJSR/mostly+static+name+resolution

I added a big comment... and I will soon give a page with my idea.

bye blackdrag
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] name resolution rules somewhere? (dynamic vs. static lookups)

Jochen Theodorou
In reply to this post by John Rose-2
John Rose schrieb:

[...]
> I just posted such a description here:
> http://docs.codehaus.org/display/GroovyJSR/mostly+static+name+resolution

I too:
http://docs.codehaus.org/display/GroovyJSR/dynamic+name+resolution

it's not complete I think, but it's something that can be discussed

bye blackdrag

Reply | Threaded
Open this post in threaded view
|

RE: [groovy-jsr] name resolution rules somewhere? (dynamic vs. static lookups)

Dierk König
class A {
  private def foo(Integer i){1}
  def foo(o){2}
  def bar(o){foo(o)}
}

class B extends A {
  def foo(Integer i) {3}
  def foo(String s)  {4}
}

def b = new B()
assert b.foo(1)   == 3
assert b.foo(1.0) == 2
assert b.foo("1") == 4
assert b.bar(1)   == 1  // I don't get it. Why is this not 3 ?
assert b.bar(1.0) == 2
assert b.bar("1") == 4

very good page and explanations!

Thanx a lot
Mittie


> -----Original Message-----
> From: Jochen Theodorou [mailto:[hidden email]]
> Sent: Mittwoch, 16. November 2005 21:25
> To: [hidden email]
> Subject: Re: [groovy-jsr] name resolution rules somewhere? (dynamic vs.
> static lookups)
>
>
> John Rose schrieb:
>
> [...]
> > I just posted such a description here:
> > http://docs.codehaus.org/display/GroovyJSR/mostly+static+name+resolution
>
> I too:
> http://docs.codehaus.org/display/GroovyJSR/dynamic+name+resolution
>
> it's not complete I think, but it's something that can be discussed
>
> bye blackdrag

123