29 May
2010
29 May
'10
7:28 p.m.
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."
29 May
29 May
7:49 p.m.
#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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Lukas Renggli
www.lukas-renggli.ch
9:03 p.m.
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
--
Lukas Renggli
www.lukas-renggli.ch
9:57 p.m.
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: 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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:32 p.m.
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
30 May
30 May
9:53 a.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:18 a.m.
There is already #isSelfSend and #isSuperSend in RBMessageNode from John Brant.
Lukas
On 30 May 2010 09:53, Stéphane Ducasse <stephane.ducasse(a)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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Lukas Renggli
www.lukas-renggli.ch
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:33 p.m.
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(a)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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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
--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5089
days inactive
5090
days old
7 comments
3 participants
participants (3)
-
Lukas Renggli -
Stéphane Ducasse -
Tudor Girba