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 <guillermopol...@gmail.com> wrote: > > Ahh explicitness :) > >> On Thu, May 3, 2018 at 10:56 AM, Tudor Girba <tu...@tudorgirba.com> wrote: >> How about: #newAst & #cachedAst? >> >> 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?" > > > > -- > > 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
