> On 3 May 2018, at 10:56, Tudor Girba <tu...@tudorgirba.com> wrote: > > How about: #newAst & #cachedAst?
Best suggestion yet. +1 > Cheers, > Doru > > >> On May 3, 2018, at 9:30 AM, Guillermo Polito <guillermopol...@gmail.com> >> wrote: >> >> method newAst ? >> >> On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras >> <vonbecm...@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.sarg...@gemtalksystems.com> wrote: >> On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <dionisi...@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.den...@inria.fr>: >> >> >>> On 27 Apr 2018, at 21:36, Sean P. DeNigris <s...@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?" > >
