ast-semantic

> 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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>

> #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 <[hidden email]> 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
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> 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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> 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
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev