I am looking at the AST of a method like this: someMethod ^ SomeClass new It was a surprise to me that the note for 'SomeClass' is an RBVariableNode instead of a RBClassReference. Which is the best way to tell if an RBVariableNode represents a global reference or an instance variable? On the other hand, there are no references to RBClassReference, so this might be a bug? Thanks, Nico
On 09 Jan 2014, at 01:57, Nicolas Passerini <npasserini@gmail.com> wrote:
I am looking at the AST of a method like this:
someMethod ^ SomeClass new
It was a surprise to me that the note for 'SomeClass' is an RBVariableNode instead of a RBClassReference. Which is the best way to tell if an RBVariableNode represents a global reference or an instance variable?
Yes, is is a known bug. Camillo added that the Parser already specialises variables, but in the end, the code is quite complex *and* it mixes grammar related things with semantics. So the idea is to move that into the sen check phase. (the complexity shows by the fact that we just could not fix the bug⦠there is a reason why one should not mix pure syntax with semantics concerns)
On the other hand, there are no references to RBClassReference, so this might be a bug?
No, all the specialised variable nodes are right now not used. What Opal does is to do the analysis in a second phase and to *annotate* all vars with âsemanticâ variable descriptors. So the right way to check for globals is to use isGlobal which does "^self binding isGlobalâ⦠You need to make sure to do semantic analysis on the AST before calling, see #doSemanticAnalysis in RBMethodNode. I really should clean it up.. this is more hurting than helping now. Marcus
On 09 Jan 2014, at 07:51, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 01:57, Nicolas Passerini <npasserini@gmail.com> wrote:
I am looking at the AST of a method like this:
someMethod ^ SomeClass new
It was a surprise to me that the note for 'SomeClass' is an RBVariableNode instead of a RBClassReference. Which is the best way to tell if an RBVariableNode represents a global reference or an instance variable?
Yes, is is a known bug. Camillo added that the Parser already specialises variables, but in the end, the code is quite complex *and* it mixes grammar related things with semantics.
So the idea is to move that into the sen check phase.
(the complexity shows by the fact that we just could not fix the bug⦠there is a reason why one should not mix pure syntax with semantics concerns)
https://pharo.fogbugz.com/f/cases/10916/RBParser-missparse-some-temporary-va... I will put it higher on my TODO list. Marcus
Le 09/01/2014 01:57, Nicolas Passerini a écrit :
I am looking at the AST of a method like this:
someMethod ^ SomeClass new
It was a surprise to me that the note for 'SomeClass' is an RBVariableNode instead of a RBClassReference. Which is the best way to tell if an RBVariableNode represents a global reference or an instance variable?
You test the binding associated with the RBVariableNode self binding isInstance -> instance variable name self binding isLiteral or: [ self isGlobal] Class reference or a global reference (singleton) or a literal self binding isTemp -> temporary Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Thank you Markus and Thierry, I will try that. On Thu, Jan 9, 2014 at 5:10 AM, Goubier Thierry <thierry.goubier@cea.fr>wrote:
Le 09/01/2014 01:57, Nicolas Passerini a écrit :
I am looking at the AST of a method like this:
someMethod ^ SomeClass new
It was a surprise to me that the note for 'SomeClass' is an RBVariableNode instead of a RBClassReference. Which is the best way to tell if an RBVariableNode represents a global reference or an instance variable?
You test the binding associated with the RBVariableNode
self binding isInstance -> instance variable name
self binding isLiteral or: [ self isGlobal] Class reference or a global reference (singleton) or a literal
self binding isTemp -> temporary
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
participants (3)
-
Goubier Thierry -
Marcus Denker -
Nicolas Passerini