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.sargent@ > 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-Differen >>>> ce-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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
