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