On Thu, May 3, 2018 at 10:56 AM, Tudor Girba <tudor@tudorgirba.com> wrote:

How about: #newAst & #cachedAst?

Cheers,
Doru


> On May 3, 2018, at 9:30 AM, Guillermo Polito <guillermopolito@gmail.com> wrote:
>
> method newAst ?
>
> On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras <vonbecmann@gmail.com> 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 <richard.sargent@gemtalksystems.com> wrote:
> On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <dionisiydk@gmail.com> 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 <marcus.denker@inria.fr>:
>
>
> > On 27 Apr 2018, at 21:36, Sean P. DeNigris <sean@clipperadams.com> 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?"