#ast vs. #parseTree

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

#ast vs. #parseTree

Sean P. DeNigris
Administrator
Why does CompiledMethod understand both? They are in the same protocol, produce the same kindOf result, and neither has a method comment! :/ (Pharo 4.0)
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Marcus Denker-4
#ast returns a result from the cache, while #parseTree always gets a new one…

yes, it could be documented. Yes, it could be better. Like always.

        Marcus

> On 30 Apr 2016, at 22:25, Sean P. DeNigris <[hidden email]> wrote:
>
> Why does CompiledMethod understand both? They are in the same protocol,
> produce the same kindOf result, and neither has a method comment! :/ (Pharo
> 4.0)
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/ast-vs-parseTree-tp4893074.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Sean P. DeNigris
Administrator
Marcus Denker-4 wrote
#ast returns a result from the cache, while #parseTree always gets a new one…
Ah, okay. What is the difference? That is, how/when is the cache updated?

Marcus Denker-4 wrote
Yes, it could be better. Like always.
:)
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

stepharo
In reply to this post by Sean P. DeNigris
marcus may be we should slowly deprecated ast into cachedParseTree or
something like that.


Le 30/4/16 à 22:25, Sean P. DeNigris a écrit :

> Why does CompiledMethod understand both? They are in the same protocol,
> produce the same kindOf result, and neither has a method comment! :/ (Pharo
> 4.0)
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/ast-vs-parseTree-tp4893074.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Marcus Denker-4
In reply to this post by Sean P. DeNigris

> On 01 May 2016, at 14:45, Sean P. DeNigris <[hidden email]> wrote:
>
> Marcus Denker-4 wrote
>> #ast returns a result from the cache, while #parseTree always gets a new
>> one…
>
> Ah, okay. What is the difference? That is, how/when is the cache updated?
>

-> added on first call of #ast
-> cleaned on image shutdown.

This is not yet really good, but works amazingly well for being so simple.

I want to change it to be LRU and not grow too large… clients that are interested
in persisting the AST (e.g. due to annotations) do that now already to survive shutdown.

E.g. if you put a breakpoint, the AST of *that* method will survive shutdown… so a LRU cache
would not change that.

>
> Marcus Denker-4 wrote
>> Yes, it could be better. Like always.
>
> :)

I will add comments… and the API should be improved, too, but not now.


        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Sean P. DeNigris
Administrator
Marcus Denker-4 wrote
> I will add comments…

I got confused by this again and created an issue:
https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-and-parseTree

And then Peter Uhnak reminded me on Discord about this thread. I'm happy to
add the comments, but not sure I understand the issue well enough. IIUC #ast
is cached, but #parseTree is not. What I don't understand is the purpose of
this difference and when one would use one over the other. For example,
when, if ever, would a user want to access a CM's #ast (as opposed to
#parseTree) and could modifying it create problems?





-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Marcus Denker-4


> On 27 Apr 2018, at 21:36, Sean P. DeNigris <[hidden email]> wrote:
>
> Marcus Denker-4 wrote
>> I will add comments…
>
> I got confused by this again and created an issue:
> https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-and-parseTree
>
> And then Peter Uhnak reminded me on Discord about this thread. I'm happy to
> add the comments, but not sure I understand the issue well enough. IIUC #ast
> is cached, but #parseTree is not. What I don't understand is the purpose of
> this difference and when one would use one over the other.

the cached #ast is for one interesting for speed (that is, in situations where you ask for it often).

The other use-case is if you want to annotate the AST and keep that annotation around (till the next
image save, but you can subscribe to ASTCacheReset and re-install the AST in the cache after cleaning.
(This is used by MetaLinks to make sure they survive image restart).

The last thing that it provides is that we do have a quite powerful mapping between bytecode/text/context
and the AST. Regardless how you navigate, you get the same object.

e.g. even this one works:

        [ 1+2 ] sourceNode == thisContext method ast blockNodes first

> For example,
> when, if ever, would a user want to access a CM's #ast (as opposed to
> #parseTree) and could modifying it create problems?
>

Modification is a problem, yes.. code that wants to modify the AST without making sure the compiledMethod is in sync later
should use #parseTree.

Code that does not modify the AST (or makes sure to compile it after modification) is free to use #ast.
or if you want to annotate the AST (which is a modification, after all).

This is not perfect (not at all…) but the simplest solution to get (to some extend) what you would have if the system would have
a real persistent, first class AST…

To be improved. The ASTCache with it’s naive “lets just cache everything till the next image save” was done with the idea to see
when it would show that it is too naive… for that it worked amazingly well till now.

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Sean P. DeNigris
Administrator
Marcus Denker-4 wrote
> the cached #ast is for one interesting…

Thanks! Very interesting :)



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Marcus Denker-4


> On 2 May 2018, at 17:34, Sean P. DeNigris <[hidden email]> wrote:
>
> Marcus Denker-4 wrote
>> the cached #ast is for one interesting…
>
> Thanks! Very interesting :)
>

In the end I think what I really would like to have is a Smalltalk with a “first class” and persistent AST
(or AST-like data structure)…

Another of these lies: “Smalltalk has textual source code, everything is an object”.. of course hard to pull
odd with the memory and CPU resources of many decades ago, but today one could build that system for real!


        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Denis Kudriashov
In reply to this post by Marcus Denker-4
Hi.

Maybe #parseSourceCode would be better name for #parseTree. 

2018-05-02 16:33 GMT+03:00 Marcus Denker <[hidden email]>:


> On 27 Apr 2018, at 21:36, Sean P. DeNigris <[hidden email]> wrote:
>
> Marcus Denker-4 wrote
>> I will add comments…
>
> I got confused by this again and created an issue:
> https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-and-parseTree
>
> And then Peter Uhnak reminded me on Discord about this thread. I'm happy to
> add the comments, but not sure I understand the issue well enough. IIUC #ast
> is cached, but #parseTree is not. What I don't understand is the purpose of
> this difference and when one would use one over the other.

the cached #ast is for one interesting for speed (that is, in situations where you ask for it often).

The other use-case is if you want to annotate the AST and keep that annotation around (till the next
image save, but you can subscribe to ASTCacheReset and re-install the AST in the cache after cleaning.
(This is used by MetaLinks to make sure they survive image restart).

The last thing that it provides is that we do have a quite powerful mapping between bytecode/text/context
and the AST. Regardless how you navigate, you get the same object.

e.g. even this one works:

        [ 1+2 ] sourceNode == thisContext method ast blockNodes first

> For example,
> when, if ever, would a user want to access a CM's #ast (as opposed to
> #parseTree) and could modifying it create problems?
>

Modification is a problem, yes.. code that wants to modify the AST without making sure the compiledMethod is in sync later
should use #parseTree.

Code that does not modify the AST (or makes sure to compile it after modification) is free to use #ast.
or if you want to annotate the AST (which is a modification, after all).

This is not perfect (not at all…) but the simplest solution to get (to some extend) what you would have if the system would have
a real persistent, first class AST…

To be improved. The ASTCache with it’s naive “lets just cache everything till the next image save” was done with the idea to see
when it would show that it is too naive… for that it worked amazingly well till now.

        Marcus

Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Richard Sargent
Administrator
On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <[hidden email]> wrote:
Hi.

Maybe #parseSourceCode would be better name for #parseTree. 

I've always found it good advice to avoid using a verb phrase to name something which does not entail some kind of action.
#parseSourceCode realy reads like something which would parse the source code. #parseTree also has that effect, except for the lack of a tree to parse.

 

2018-05-02 16:33 GMT+03:00 Marcus Denker <[hidden email]>:


> On 27 Apr 2018, at 21:36, Sean P. DeNigris <[hidden email]> wrote:
>
> Marcus Denker-4 wrote
>> I will add comments…
>
> I got confused by this again and created an issue:
> https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-and-parseTree
>
> And then Peter Uhnak reminded me on Discord about this thread. I'm happy to
> add the comments, but not sure I understand the issue well enough. IIUC #ast
> is cached, but #parseTree is not. What I don't understand is the purpose of
> this difference and when one would use one over the other.

the cached #ast is for one interesting for speed (that is, in situations where you ask for it often).

The other use-case is if you want to annotate the AST and keep that annotation around (till the next
image save, but you can subscribe to ASTCacheReset and re-install the AST in the cache after cleaning.
(This is used by MetaLinks to make sure they survive image restart).

The last thing that it provides is that we do have a quite powerful mapping between bytecode/text/context
and the AST. Regardless how you navigate, you get the same object.

e.g. even this one works:

        [ 1+2 ] sourceNode == thisContext method ast blockNodes first

> For example,
> when, if ever, would a user want to access a CM's #ast (as opposed to
> #parseTree) and could modifying it create problems?
>

Modification is a problem, yes.. code that wants to modify the AST without making sure the compiledMethod is in sync later
should use #parseTree.

Code that does not modify the AST (or makes sure to compile it after modification) is free to use #ast.
or if you want to annotate the AST (which is a modification, after all).

This is not perfect (not at all…) but the simplest solution to get (to some extend) what you would have if the system would have
a real persistent, first class AST…

To be improved. The ASTCache with it’s naive “lets just cache everything till the next image save” was done with the idea to see
when it would show that it is too naive… for that it worked amazingly well till now.

        Marcus


Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

vonbecmann
a "parse tree" is not equal to an "ast"(abstract syntax tree)
but its difficult to find a name for an ast that is not cached.
maybe 
parsedAst
parseAst
....


On Wed, May 2, 2018 at 3:28 PM, Richard Sargent <[hidden email]> wrote:
On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <[hidden email]> wrote:
Hi.

Maybe #parseSourceCode would be better name for #parseTree. 

I've always found it good advice to avoid using a verb phrase to name something which does not entail some kind of action.
#parseSourceCode realy reads like something which would parse the source code. #parseTree also has that effect, except for the lack of a tree to parse.

 

2018-05-02 16:33 GMT+03:00 Marcus Denker <[hidden email]>:


> On 27 Apr 2018, at 21:36, Sean P. DeNigris <[hidden email]> wrote:
>
> Marcus Denker-4 wrote
>> I will add comments…
>
> I got confused by this again and created an issue:
> https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-and-parseTree
>
> And then Peter Uhnak reminded me on Discord about this thread. I'm happy to
> add the comments, but not sure I understand the issue well enough. IIUC #ast
> is cached, but #parseTree is not. What I don't understand is the purpose of
> this difference and when one would use one over the other.

the cached #ast is for one interesting for speed (that is, in situations where you ask for it often).

The other use-case is if you want to annotate the AST and keep that annotation around (till the next
image save, but you can subscribe to ASTCacheReset and re-install the AST in the cache after cleaning.
(This is used by MetaLinks to make sure they survive image restart).

The last thing that it provides is that we do have a quite powerful mapping between bytecode/text/context
and the AST. Regardless how you navigate, you get the same object.

e.g. even this one works:

        [ 1+2 ] sourceNode == thisContext method ast blockNodes first

> For example,
> when, if ever, would a user want to access a CM's #ast (as opposed to
> #parseTree) and could modifying it create problems?
>

Modification is a problem, yes.. code that wants to modify the AST without making sure the compiledMethod is in sync later
should use #parseTree.

Code that does not modify the AST (or makes sure to compile it after modification) is free to use #ast.
or if you want to annotate the AST (which is a modification, after all).

This is not perfect (not at all…) but the simplest solution to get (to some extend) what you would have if the system would have
a real persistent, first class AST…

To be improved. The ASTCache with it’s naive “lets just cache everything till the next image save” was done with the idea to see
when it would show that it is too naive… for that it worked amazingly well till now.

        Marcus





--
Bernardo E.C.

Sent from a cheap desktop computer in South America.
Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Guillermo Polito
method newAst ?

On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras <[hidden email]> wrote:
a "parse tree" is not equal to an "ast"(abstract syntax tree)
but its difficult to find a name for an ast that is not cached.
maybe 
parsedAst
parseAst
....


On Wed, May 2, 2018 at 3:28 PM, Richard Sargent <[hidden email]> wrote:
On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <[hidden email]> wrote:
Hi.

Maybe #parseSourceCode would be better name for #parseTree. 

I've always found it good advice to avoid using a verb phrase to name something which does not entail some kind of action.
#parseSourceCode realy reads like something which would parse the source code. #parseTree also has that effect, except for the lack of a tree to parse.

 

2018-05-02 16:33 GMT+03:00 Marcus Denker <[hidden email]>:


> On 27 Apr 2018, at 21:36, Sean P. DeNigris <[hidden email]> wrote:
>
> Marcus Denker-4 wrote
>> I will add comments…
>
> I got confused by this again and created an issue:
> https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-and-parseTree
>
> And then Peter Uhnak reminded me on Discord about this thread. I'm happy to
> add the comments, but not sure I understand the issue well enough. IIUC #ast
> is cached, but #parseTree is not. What I don't understand is the purpose of
> this difference and when one would use one over the other.

the cached #ast is for one interesting for speed (that is, in situations where you ask for it often).

The other use-case is if you want to annotate the AST and keep that annotation around (till the next
image save, but you can subscribe to ASTCacheReset and re-install the AST in the cache after cleaning.
(This is used by MetaLinks to make sure they survive image restart).

The last thing that it provides is that we do have a quite powerful mapping between bytecode/text/context
and the AST. Regardless how you navigate, you get the same object.

e.g. even this one works:

        [ 1+2 ] sourceNode == thisContext method ast blockNodes first

> For example,
> when, if ever, would a user want to access a CM's #ast (as opposed to
> #parseTree) and could modifying it create problems?
>

Modification is a problem, yes.. code that wants to modify the AST without making sure the compiledMethod is in sync later
should use #parseTree.

Code that does not modify the AST (or makes sure to compile it after modification) is free to use #ast.
or if you want to annotate the AST (which is a modification, after all).

This is not perfect (not at all…) but the simplest solution to get (to some extend) what you would have if the system would have
a real persistent, first class AST…

To be improved. The ASTCache with it’s naive “lets just cache everything till the next image save” was done with the idea to see
when it would show that it is too naive… for that it worked amazingly well till now.

        Marcus





--
Bernardo E.C.

Sent from a cheap desktop computer in South America.



--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Tudor Girba-2
How about: #newAst & #cachedAst?

Cheers,
Doru


> On May 3, 2018, at 9:30 AM, Guillermo Polito <[hidden email]> wrote:
>
> method newAst ?
>
> On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras <[hidden email]> wrote:
> a "parse tree" is not equal to an "ast"(abstract syntax tree)
> but its difficult to find a name for an ast that is not cached.
> maybe
> parsedAst
> parseAst
> ....
>
>
> On Wed, May 2, 2018 at 3:28 PM, Richard Sargent <[hidden email]> wrote:
> On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <[hidden email]> wrote:
> Hi.
>
> Maybe #parseSourceCode would be better name for #parseTree.
>
> I've always found it good advice to avoid using a verb phrase to name something which does not entail some kind of action.
> #parseSourceCode realy reads like something which would parse the source code. #parseTree also has that effect, except for the lack of a tree to parse.
>
>  
>
> 2018-05-02 16:33 GMT+03:00 Marcus Denker <[hidden email]>:
>
>
> > On 27 Apr 2018, at 21:36, Sean P. DeNigris <[hidden email]> wrote:
> >
> > Marcus Denker-4 wrote
> >> I will add comments…
> >
> > I got confused by this again and created an issue:
> > https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-and-parseTree
> >
> > And then Peter Uhnak reminded me on Discord about this thread. I'm happy to
> > add the comments, but not sure I understand the issue well enough. IIUC #ast
> > is cached, but #parseTree is not. What I don't understand is the purpose of
> > this difference and when one would use one over the other.
>
> the cached #ast is for one interesting for speed (that is, in situations where you ask for it often).
>
> The other use-case is if you want to annotate the AST and keep that annotation around (till the next
> image save, but you can subscribe to ASTCacheReset and re-install the AST in the cache after cleaning.
> (This is used by MetaLinks to make sure they survive image restart).
>
> The last thing that it provides is that we do have a quite powerful mapping between bytecode/text/context
> and the AST. Regardless how you navigate, you get the same object.
>
> e.g. even this one works:
>
>         [ 1+2 ] sourceNode == thisContext method ast blockNodes first
>
> > For example,
> > when, if ever, would a user want to access a CM's #ast (as opposed to
> > #parseTree) and could modifying it create problems?
> >
>
> Modification is a problem, yes.. code that wants to modify the AST without making sure the compiledMethod is in sync later
> should use #parseTree.
>
> Code that does not modify the AST (or makes sure to compile it after modification) is free to use #ast.
> or if you want to annotate the AST (which is a modification, after all).
>
> This is not perfect (not at all…) but the simplest solution to get (to some extend) what you would have if the system would have
> a real persistent, first class AST…
>
> To be improved. The ASTCache with it’s naive “lets just cache everything till the next image save” was done with the idea to see
> when it would show that it is too naive… for that it worked amazingly well till now.
>
>         Marcus
>
>
>
>
>
> --
> Bernardo E.C.
>
> Sent from a cheap desktop computer in South America.
>
>
>
> --
>    
> Guille Polito
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr
>
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13

--
www.tudorgirba.com
www.feenk.com

"What is more important: To be happy, or to make happy?"


Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Guillermo Polito
Ahh explicitness :)

On Thu, May 3, 2018 at 10:56 AM, Tudor Girba <[hidden email]> wrote:
How about: #newAst & #cachedAst?

Cheers,
Doru


> On May 3, 2018, at 9:30 AM, Guillermo Polito <[hidden email]> wrote:
>
> method newAst ?
>
> On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras <[hidden email]> wrote:
> a "parse tree" is not equal to an "ast"(abstract syntax tree)
> but its difficult to find a name for an ast that is not cached.
> maybe
> parsedAst
> parseAst
> ....
>
>
> On Wed, May 2, 2018 at 3:28 PM, Richard Sargent <[hidden email]> wrote:
> On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <[hidden email]> wrote:
> Hi.
>
> Maybe #parseSourceCode would be better name for #parseTree.
>
> I've always found it good advice to avoid using a verb phrase to name something which does not entail some kind of action.
> #parseSourceCode realy reads like something which would parse the source code. #parseTree also has that effect, except for the lack of a tree to parse.
>

>
> 2018-05-02 16:33 GMT+03:00 Marcus Denker <[hidden email]>:
>
>
> > On 27 Apr 2018, at 21:36, Sean P. DeNigris <[hidden email]> wrote:
> >
> > Marcus Denker-4 wrote
> >> I will add comments…
> >
> > I got confused by this again and created an issue:
> > https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-and-parseTree
> >
> > And then Peter Uhnak reminded me on Discord about this thread. I'm happy to
> > add the comments, but not sure I understand the issue well enough. IIUC #ast
> > is cached, but #parseTree is not. What I don't understand is the purpose of
> > this difference and when one would use one over the other.
>
> the cached #ast is for one interesting for speed (that is, in situations where you ask for it often).
>
> The other use-case is if you want to annotate the AST and keep that annotation around (till the next
> image save, but you can subscribe to ASTCacheReset and re-install the AST in the cache after cleaning.
> (This is used by MetaLinks to make sure they survive image restart).
>
> The last thing that it provides is that we do have a quite powerful mapping between bytecode/text/context
> and the AST. Regardless how you navigate, you get the same object.
>
> e.g. even this one works:
>
>         [ 1+2 ] sourceNode == thisContext method ast blockNodes first
>
> > For example,
> > when, if ever, would a user want to access a CM's #ast (as opposed to
> > #parseTree) and could modifying it create problems?
> >
>
> Modification is a problem, yes.. code that wants to modify the AST without making sure the compiledMethod is in sync later
> should use #parseTree.
>
> Code that does not modify the AST (or makes sure to compile it after modification) is free to use #ast.
> or if you want to annotate the AST (which is a modification, after all).
>
> This is not perfect (not at all…) but the simplest solution to get (to some extend) what you would have if the system would have
> a real persistent, first class AST…
>
> To be improved. The ASTCache with it’s naive “lets just cache everything till the next image save” was done with the idea to see
> when it would show that it is too naive… for that it worked amazingly well till now.
>
>         Marcus
>
>
>
>
>
> --
> Bernardo E.C.
>
> Sent from a cheap desktop computer in South America.
>
>
>
> --
>   
> Guille Polito
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr
>
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13

--
www.tudorgirba.com
www.feenk.com

"What is more important: To be happy, or to make happy?"





--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Sean P. DeNigris
Administrator
Guillermo Polito wrote
> Ahh explicitness :)

+1!



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Francisco Garau-2
In reply to this post by Guillermo Polito
I'd rather be also explicit in the name and avoid acronyms. #newAbstractSyntaxTree and #cachedAbstractSyntaxTree

- Francisco


On 3 May 2018, at 09:59, Guillermo Polito <[hidden email]> wrote:

Ahh explicitness :)

On Thu, May 3, 2018 at 10:56 AM, Tudor Girba <[hidden email]> wrote:
How about: #newAst & #cachedAst?

Cheers,
Doru


> On May 3, 2018, at 9:30 AM, Guillermo Polito <[hidden email]> wrote:
>
> method newAst ?
>
> On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras <[hidden email]> wrote:
> a "parse tree" is not equal to an "ast"(abstract syntax tree)
> but its difficult to find a name for an ast that is not cached.
> maybe
> parsedAst
> parseAst
> ....
>
>
> On Wed, May 2, 2018 at 3:28 PM, Richard Sargent <[hidden email]> wrote:
> On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <[hidden email]> wrote:
> Hi.
>
> Maybe #parseSourceCode would be better name for #parseTree.
>
> I've always found it good advice to avoid using a verb phrase to name something which does not entail some kind of action.
> #parseSourceCode realy reads like something which would parse the source code. #parseTree also has that effect, except for the lack of a tree to parse.
>

>
> 2018-05-02 16:33 GMT+03:00 Marcus Denker <[hidden email]>:
>
>
> > On 27 Apr 2018, at 21:36, Sean P. DeNigris <[hidden email]> wrote:
> >
> > Marcus Denker-4 wrote
> >> I will add comments…
> >
> > I got confused by this again and created an issue:
> > https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-and-parseTree
> >
> > And then Peter Uhnak reminded me on Discord about this thread. I'm happy to
> > add the comments, but not sure I understand the issue well enough. IIUC #ast
> > is cached, but #parseTree is not. What I don't understand is the purpose of
> > this difference and when one would use one over the other.
>
> the cached #ast is for one interesting for speed (that is, in situations where you ask for it often).
>
> The other use-case is if you want to annotate the AST and keep that annotation around (till the next
> image save, but you can subscribe to ASTCacheReset and re-install the AST in the cache after cleaning.
> (This is used by MetaLinks to make sure they survive image restart).
>
> The last thing that it provides is that we do have a quite powerful mapping between bytecode/text/context
> and the AST. Regardless how you navigate, you get the same object.
>
> e.g. even this one works:
>
>         [ 1+2 ] sourceNode == thisContext method ast blockNodes first
>
> > For example,
> > when, if ever, would a user want to access a CM's #ast (as opposed to
> > #parseTree) and could modifying it create problems?
> >
>
> Modification is a problem, yes.. code that wants to modify the AST without making sure the compiledMethod is in sync later
> should use #parseTree.
>
> Code that does not modify the AST (or makes sure to compile it after modification) is free to use #ast.
> or if you want to annotate the AST (which is a modification, after all).
>
> This is not perfect (not at all…) but the simplest solution to get (to some extend) what you would have if the system would have
> a real persistent, first class AST…
>
> To be improved. The ASTCache with it’s naive “lets just cache everything till the next image save” was done with the idea to see
> when it would show that it is too naive… for that it worked amazingly well till now.
>
>         Marcus
>
>
>
>
>
> --
> Bernardo E.C.
>
> Sent from a cheap desktop computer in South America.
>
>
>
> --
>   
> Guille Polito
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr
>
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13

--
www.tudorgirba.com
www.feenk.com

"What is more important: To be happy, or to make happy?"





--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Esteban A. Maringolo
+1 to avoid acronyms.

Esteban A. Maringolo

2018-05-03 12:47 GMT-03:00 Francisco Garau <[hidden email]>:
I'd rather be also explicit in the name and avoid acronyms. #newAbstractSyntaxTree and #cachedAbstractSyntaxTree

- Francisco


Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Guillermo Polito
I don't think so... any compiler book talks about ASTs using acronyms. Acronyms are good when acronyms are good.

Le jeu. 3 mai 2018 à 20:48, Esteban A. Maringolo <[hidden email]> a écrit :
+1 to avoid acronyms.

Esteban A. Maringolo

2018-05-03 12:47 GMT-03:00 Francisco Garau <[hidden email]>:
I'd rather be also explicit in the name and avoid acronyms. #newAbstractSyntaxTree and #cachedAbstractSyntaxTree

- Francisco


--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Francisco Garau-2
There is quite a difference between a compiler book using the AST acronym and a message with the #ast selector. 

Whoever starts reading a compiler book already knows about AST. We shouldn't assume the same about any Pharo developer. 

- Francisco


On 3 May 2018, at 20:02, Guillermo Polito <[hidden email]> wrote:

I don't think so... any compiler book talks about ASTs using acronyms. Acronyms are good when acronyms are good.

Le jeu. 3 mai 2018 à 20:48, Esteban A. Maringolo <[hidden email]> a écrit :
+1 to avoid acronyms.

Esteban A. Maringolo

2018-05-03 12:47 GMT-03:00 Francisco Garau <[hidden email]>:
I'd rather be also explicit in the name and avoid acronyms. #newAbstractSyntaxTree and #cachedAbstractSyntaxTree

- Francisco


--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

123