Hi,
I am looking into AST-Semantic. I found the one from the http://www.squeaksource.com/rb .
However, this one does not have the methods: - RBProgramNode>>isSuper - RBVariableNode>>isSuper
These are needed for the SmalltalkImporter.
Am I looking at the wrong repository, or are these methods just missing?
Cheers, Doru
-- www.tudorgirba.com
"When people care, great things can happen."
#isSuper is not related to AST-Semantics. As far as I know from Veronica this was an extension method merely comparing the name of the variable with the string 'super'.
AST-Semantics is an attempt in providing correct scope and variable binding information (so that it can also be used by a compiler for example, or Helvetia in my case). In fact it can tell you if two variables refer to the same object or just happen to have the same name. Also it can tell you the scope in which the variable is visible and all its readers and writers.
Providing all that information comes at a small price, it is slightly more complicated to use and requires a few extra steps. If you want to annotate an AST with semantic information you have to tell it in what scope (e.g. the class) is used (I guess that should be simplified):
RBSemanticAnnotator new start: aTree class: aClass
From then on all variables have a #variableBinding object that
uniquely identifies variables that refer to the same thing. You can then ask a variable if it is a super call, and more ...
aVariableNode variableBinding isSuperBinding
Lukas
On 29 May 2010 19:28, Tudor Girba tudor.girba@gmail.com wrote:
Hi,
I am looking into AST-Semantic. I found the one from the http://www.squeaksource.com/rb.
However, this one does not have the methods:
- RBProgramNode>>isSuper
- RBVariableNode>>isSuper
These are needed for the SmalltalkImporter.
Am I looking at the wrong repository, or are these methods just missing?
Cheers, Doru
-- www.tudorgirba.com
"When people care, great things can happen."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Providing all that information comes at a small price, it is slightly more complicated to use and requires a few extra steps. If you want to annotate an AST with semantic information you have to tell it in what scope (e.g. the class) is used (I guess that should be simplified):
RBSemanticAnnotator new start: aTree class: aClass
In the latest version you can use #annotateInClass: to specify the class-scope in which the AST should be interpreted, for example:
(RBParser parseMethod: aString) annotateInClass: aClass
Lukas
but lukas why we cannot simply know if a variable is named super and self. Because normally it should be accepted as something by the compiler or we should fix the compiler.
On May 29, 2010, at 7:49 PM, Lukas Renggli wrote:
#isSuper is not related to AST-Semantics. As far as I know from Veronica this was an extension method merely comparing the name of the variable with the string 'super'.
AST-Semantics is an attempt in providing correct scope and variable binding information (so that it can also be used by a compiler for example, or Helvetia in my case). In fact it can tell you if two variables refer to the same object or just happen to have the same name. Also it can tell you the scope in which the variable is visible and all its readers and writers.
Providing all that information comes at a small price, it is slightly more complicated to use and requires a few extra steps. If you want to annotate an AST with semantic information you have to tell it in what scope (e.g. the class) is used (I guess that should be simplified):
RBSemanticAnnotator new start: aTree class: aClassFrom then on all variables have a #variableBinding object that
uniquely identifies variables that refer to the same thing. You can then ask a variable if it is a super call, and more ...
aVariableNode variableBinding isSuperBinding
Lukas
On 29 May 2010 19:28, Tudor Girba tudor.girba@gmail.com wrote:
Hi,
I am looking into AST-Semantic. I found the one from the http://www.squeaksource.com/rb.
However, this one does not have the methods:
- RBProgramNode>>isSuper
- RBVariableNode>>isSuper
These are needed for the SmalltalkImporter.
Am I looking at the wrong repository, or are these methods just missing?
Cheers, Doru
-- www.tudorgirba.com
"When people care, great things can happen."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
why we cannot simply know if a variable is named super and self.
Of course, you can simply write
aVariableNode name = 'self'
and then you know that your variable is called 'self', but nothing more. I am not saying that this is wrong, it is likely to be correct in most cases and probably enough for most code analysis scenarios. IMHO, it should then also written like that to reveal its intention.
Because normally it should be accepted as something by the compiler or we should fix the compiler.
The Pharo compiler does not compile code with instance/temporary/argument variables that shadow 'self', 'super', 'thisContext', 'true', 'false', or 'nil' (Jorge fixed that). However other compilers might not insist on that, or you might end up with syntactically correct code that never went through a semantic checker. For example, the following code is syntactically perfectly valid Smalltalk:
foo: self | thisContext | super := self
Also there is an infinite number of ways variables can be shadowed without going through the compiler and without anybody complaining. And there are not even 'dirty' tricks needed to do that, just add/remove instance-, class-, or global variables in the context of existing code. In this situation anything simpler than AST-Semantic most certainly leads to wrong results.
Again, I am not saying that you have to use AST-Semantic. It is a tool that is useful if you need precise semantic information, for example for code transformations (Helvetia), a compiler (maybe the New Compiler in the future), or for semantic preserving refactorings (maybe the Refactoring Engine in the future).
Lukas
what you could do is to provide a cheap and dirty couple of methods
fuzzyIsSuper "this method used a trivial and may be incorrect strategy to determine whether the receiver is the superpseudo variable" fuzzyIsSelf
like that we can be happy
Stef
On May 29, 2010, at 11:32 PM, Lukas Renggli wrote:
why we cannot simply know if a variable is named super and self.
Of course, you can simply write
aVariableNode name = 'self'
and then you know that your variable is called 'self', but nothing more. I am not saying that this is wrong, it is likely to be correct in most cases and probably enough for most code analysis scenarios. IMHO, it should then also written like that to reveal its intention.
Because normally it should be accepted as something by the compiler or we should fix the compiler.
The Pharo compiler does not compile code with instance/temporary/argument variables that shadow 'self', 'super', 'thisContext', 'true', 'false', or 'nil' (Jorge fixed that). However other compilers might not insist on that, or you might end up with syntactically correct code that never went through a semantic checker. For example, the following code is syntactically perfectly valid Smalltalk:
foo: self | thisContext | super := selfAlso there is an infinite number of ways variables can be shadowed without going through the compiler and without anybody complaining. And there are not even 'dirty' tricks needed to do that, just add/remove instance-, class-, or global variables in the context of existing code. In this situation anything simpler than AST-Semantic most certainly leads to wrong results.
Again, I am not saying that you have to use AST-Semantic. It is a tool that is useful if you need precise semantic information, for example for code transformations (Helvetia), a compiler (maybe the New Compiler in the future), or for semantic preserving refactorings (maybe the Refactoring Engine in the future).
Lukas
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
There is already #isSelfSend and #isSuperSend in RBMessageNode from John Brant.
Lukas
On 30 May 2010 09:53, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
what you could do is to provide a cheap and dirty couple of methods
fuzzyIsSuper "this method used a trivial and may be incorrect strategy to determine whether the receiver is the superpseudo variable" fuzzyIsSelf
like that we can be happy
Stef
On May 29, 2010, at 11:32 PM, Lukas Renggli wrote:
why we cannot simply know if a variable is named super and self.
Of course, you can simply write
aVariableNode name = 'self'
and then you know that your variable is called 'self', but nothing more. I am not saying that this is wrong, it is likely to be correct in most cases and probably enough for most code analysis scenarios. IMHO, it should then also written like that to reveal its intention.
Because normally it should be accepted as something by the compiler or we should fix the compiler.
The Pharo compiler does not compile code with instance/temporary/argument variables that shadow 'self', 'super', 'thisContext', 'true', 'false', or 'nil' (Jorge fixed that). However other compilers might not insist on that, or you might end up with syntactically correct code that never went through a semantic checker. For example, the following code is syntactically perfectly valid Smalltalk:
foo: self | thisContext | super := self
Also there is an infinite number of ways variables can be shadowed without going through the compiler and without anybody complaining. And there are not even 'dirty' tricks needed to do that, just add/remove instance-, class-, or global variables in the context of existing code. In this situation anything simpler than AST-Semantic most certainly leads to wrong results.
Again, I am not saying that you have to use AST-Semantic. It is a tool that is useful if you need precise semantic information, for example for code transformations (Helvetia), a compiler (maybe the New Compiler in the future), or for semantic preserving refactorings (maybe the Refactoring Engine in the future).
Lukas
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
then excellent!
Stef
On May 30, 2010, at 10:18 AM, Lukas Renggli wrote:
There is already #isSelfSend and #isSuperSend in RBMessageNode from John Brant.
Lukas
On 30 May 2010 09:53, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
what you could do is to provide a cheap and dirty couple of methods
fuzzyIsSuper "this method used a trivial and may be incorrect strategy to determine whether the receiver is the superpseudo variable" fuzzyIsSelf
like that we can be happy
Stef
On May 29, 2010, at 11:32 PM, Lukas Renggli wrote:
why we cannot simply know if a variable is named super and self.
Of course, you can simply write
aVariableNode name = 'self'
and then you know that your variable is called 'self', but nothing more. I am not saying that this is wrong, it is likely to be correct in most cases and probably enough for most code analysis scenarios. IMHO, it should then also written like that to reveal its intention.
Because normally it should be accepted as something by the compiler or we should fix the compiler.
The Pharo compiler does not compile code with instance/temporary/argument variables that shadow 'self', 'super', 'thisContext', 'true', 'false', or 'nil' (Jorge fixed that). However other compilers might not insist on that, or you might end up with syntactically correct code that never went through a semantic checker. For example, the following code is syntactically perfectly valid Smalltalk:
foo: self | thisContext | super := selfAlso there is an infinite number of ways variables can be shadowed without going through the compiler and without anybody complaining. And there are not even 'dirty' tricks needed to do that, just add/remove instance-, class-, or global variables in the context of existing code. In this situation anything simpler than AST-Semantic most certainly leads to wrong results.
Again, I am not saying that you have to use AST-Semantic. It is a tool that is useful if you need precise semantic information, for example for code transformations (Helvetia), a compiler (maybe the New Compiler in the future), or for semantic preserving refactorings (maybe the Refactoring Engine in the future).
Lukas
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Lukas Renggli -
Stéphane Ducasse -
Tudor Girba