Smalltalk › Pharo › Pharo Smalltalk Users

#ast vs. #parseTree

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

45 messages Options

123

Sean P. DeNigris

#ast vs. #parseTree

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

Marcus Denker-4

Re: #ast vs. #parseTree

#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.
>

Sean P. DeNigris

Re: #ast vs. #parseTree

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

stepharo

Re: #ast vs. #parseTree

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.
>
>

Marcus Denker-4

Re: #ast vs. #parseTree

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

Sean P. DeNigris

Re: #ast vs. #parseTree

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

Marcus Denker-4

Re: #ast vs. #parseTree

> 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

Sean P. DeNigris

Re: #ast vs. #parseTree

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

Marcus Denker-4

Re: #ast vs. #parseTree

> 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

Denis Kudriashov

Re: #ast vs. #parseTree

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

Richard Sargent

Re: #ast vs. #parseTree

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

vonbecmann

Re: #ast vs. #parseTree

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.

Guillermo Polito

Re: #ast vs. #parseTree

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

Tudor Girba-2

Re: #ast vs. #parseTree

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?"

Guillermo Polito

Re: #ast vs. #parseTree

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

Sean P. DeNigris

Re: #ast vs. #parseTree

Administrator

Guillermo Polito wrote
> Ahh explicitness :)

+1!

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

Cheers,
Sean

Francisco Garau-2

Re: #ast vs. #parseTree

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

Esteban A. Maringolo

Re: #ast vs. #parseTree

+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

Guillermo Polito

Re: #ast vs. #parseTree

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

Francisco Garau-2

Re: #ast vs. #parseTree

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