Why does CompiledMethod understand both? They are in the same protocol, produce the same kindOf result, and neither has a method comment! :/ (Pharo 4.0) ----- Cheers, Sean -- View this message in context: http://forum.world.st/ast-vs-parseTree-tp4893074.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
#ast returns a result from the cache, while #parseTree always gets a new one⦠yes, it could be documented. Yes, it could be better. Like always. Marcus
On 30 Apr 2016, at 22:25, Sean P. DeNigris <sean@clipperadams.com> wrote:
Why does CompiledMethod understand both? They are in the same protocol, produce the same kindOf result, and neither has a method comment! :/ (Pharo 4.0)
----- Cheers, Sean -- View this message in context: http://forum.world.st/ast-vs-parseTree-tp4893074.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Marcus Denker-4 wrote
#ast returns a result from the cache, while #parseTree always gets a new oneâ¦
Ah, okay. What is the difference? That is, how/when is the cache updated? Marcus Denker-4 wrote
Yes, it could be better. Like always.
:) ----- Cheers, Sean -- View this message in context: http://forum.world.st/ast-vs-parseTree-tp4893074p4893146.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On 01 May 2016, at 14:45, Sean P. DeNigris <sean@clipperadams.com> wrote:
Marcus Denker-4 wrote
#ast returns a result from the cache, while #parseTree always gets a new oneâ¦
Ah, okay. What is the difference? That is, how/when is the cache updated?
-> added on first call of #ast -> cleaned on image shutdown. This is not yet really good, but works amazingly well for being so simple. I want to change it to be LRU and not grow too large⦠clients that are interested in persisting the AST (e.g. due to annotations) do that now already to survive shutdown. E.g. if you put a breakpoint, the AST of *that* method will survive shutdown⦠so a LRU cache would not change that.
Marcus Denker-4 wrote
Yes, it could be better. Like always.
:)
I will add comments⦠and the API should be improved, too, but not now. Marcus
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-a... 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. 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? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
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-a...
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
Marcus Denker-4 wrote
the cached #ast is for one interestingâ¦
Thanks! Very interesting :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On 2 May 2018, at 17:34, Sean P. DeNigris <sean@clipperadams.com> wrote:
Marcus Denker-4 wrote
the cached #ast is for one interestingâ¦
Thanks! Very interesting :)
In the end I think what I really would like to have is a Smalltalk with a âfirst classâ and persistent AST (or AST-like data structure)⦠Another of these lies: âSmalltalk has textual source code, everything is an objectâ.. of course hard to pull odd with the memory and CPU resources of many decades ago, but today one could build that system for real! Marcus
Hi. Maybe #parseSourceCode would be better name for #parseTree. 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
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-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
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-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.
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-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
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-a...
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?"
Ahh explicitness :) 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?"
-- 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
Guillermo Polito wrote
Ahh explicitness :)
+1! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
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 <guillermopolito@gmail.com> wrote:
Ahh explicitness :)
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-a...
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
I don't think so... any compiler book talks about ASTs using acronyms. Acronyms are good when acronyms are good. Le jeu. 3 mai 2018 à 20:48, Esteban A. Maringolo <emaringolo@gmail.com> a écrit :
+1 to avoid acronyms.
Esteban A. Maringolo
2018-05-03 12:47 GMT-03:00 Francisco Garau <francisco.garau@gmail.com>:
I'd rather be also explicit in the name and avoid acronyms. #newAbstractSyntaxTree and #cachedAbstractSyntaxTree
- Francisco
--
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
There is quite a difference between a compiler book using the AST acronym and a message with the #ast selector. Whoever starts reading a compiler book already knows about AST. We shouldn't assume the same about any Pharo developer. - Francisco
On 3 May 2018, at 20:02, Guillermo Polito <guillermopolito@gmail.com> wrote:
I don't think so... any compiler book talks about ASTs using acronyms. Acronyms are good when acronyms are good.
Le jeu. 3 mai 2018 à 20:48, Esteban A. Maringolo <emaringolo@gmail.com> a écrit : +1 to avoid acronyms.
Esteban A. Maringolo
2018-05-03 12:47 GMT-03:00 Francisco Garau <francisco.garau@gmail.com>:
I'd rather be also explicit in the name and avoid acronyms. #newAbstractSyntaxTree and #cachedAbstractSyntaxTree
- Francisco --
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
On 05/03/2018 12:02 PM, Guillermo Polito wrote:
I don't think so... any compiler book talks about ASTs using acronyms. Acronyms are good when acronyms are good.
Boo, acronyms bad, virtually always. Jargon is awful when speaking and awful when Smalltalk'ing, use words, they're not in short supply. -- Ramon Leon
On 4 May 2018 at 08:02, Ramon Leon <ramon.leon@allresnet.com> wrote:
On 05/03/2018 12:02 PM, Guillermo Polito wrote:
I don't think so... any compiler book talks about ASTs using acronyms. Acronyms are good when acronyms are good.
Boo, acronyms bad, virtually always. Jargon is awful when speaking and awful when Smalltalk'ing, use words, they're not in short supply.
a TMA situation?
Ramon Leon-5 wrote
And my point made; I don't even know what that means.
Ha ha, I googled it and even after seeing the definition still didn't understand - we must be getting old ;-) Regarding the use of acronyms - while I agree with you as a general principle, I wonder about this case. Since the argument IIUC is that "a general user won't know the domain well enough to understand the acronym", would they understand "abstractSyntaxTree"?! That, to me, is as opaque as the acronym for one not acquainted with the domain, and may buy us little at the cost of a good amount of extra typing. Maybe keep the acronym and add a good method comment⦠----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
"Maybe keep the acronym and add a good method comment⦠" No. Please, really no. Do not use comments embedded *inside* methods to cover for naming the method badly. That is actually a counter-argument to using the acronym. Also, if one Googles an acronym, such as the recently cited TMA, one gets results like https://en.wikipedia.org/wiki/TMA (a disambiguation page with a lengthy list). [I still don't know which TMA was meant, by the way, so I can't use it for the following example.] If one Googles Abstract Syntax Tree, one will find exactly what it means. But additionally, one could make a reasonable guess at an approximation of its meaning even without searching. On Fri, May 4, 2018 at 9:45 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Ramon Leon-5 wrote
And my point made; I don't even know what that means.
Ha ha, I googled it and even after seeing the definition still didn't understand - we must be getting old ;-)
Regarding the use of acronyms - while I agree with you as a general principle, I wonder about this case. Since the argument IIUC is that "a general user won't know the domain well enough to understand the acronym", would they understand "abstractSyntaxTree"?! That, to me, is as opaque as the acronym for one not acquainted with the domain, and may buy us little at the cost of a good amount of extra typing. Maybe keep the acronym and add a good method commentâ¦
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On 04/05/2018 13:54, Richard Sargent wrote:
On Fri, May 4, 2018 at 9:45 AM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:
Ramon Leon-5 wrote > And my point made; I don't even know what that means.
Ha ha, I googled it and even after seeing the definition still didn't understand - we must be getting old ;-)
Also, if one Googles an acronym, such as the recently cited TMA, one gets results like https://en.wikipedia.org/wiki/TMA (a disambiguation page with a lengthy list). [I still don't know which TMA was meant, by the way, so I can't use it for the following example.] If one Googles Abstract Syntax Tree, one will find exactly what it means. But additionally, one could make a reasonable guess at an approximation of its meaning even without searching.
I think that the "we have a TMA situation" is a nice joke if the right guess is that TMA means "Too Many Acronyms" :) Regards! -- Esteban A. Maringolo
Just as TLA is a three letter acronym ... ð -----Original Message----- From: Pharo-users <pharo-users-bounces@lists.pharo.org> On Behalf Of Esteban A. Maringolo Sent: Friday, May 4, 2018 2:21 PM To: Any question about pharo is welcome <pharo-users@lists.pharo.org>; Richard Sargent <richard.sargent@gemtalksystems.com> Subject: Re: [Pharo-users] #ast vs. #parseTree On 04/05/2018 13:54, Richard Sargent wrote:
On Fri, May 4, 2018 at 9:45 AM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:
Ramon Leon-5 wrote > And my point made; I don't even know what that means.
Ha ha, I googled it and even after seeing the definition still didn't understand - we must be getting old ;-)
Also, if one Googles an acronym, such as the recently cited TMA, one gets results like https://en.wikipedia.org/wiki/TMA (a disambiguation page with a lengthy list). [I still don't know which TMA was meant, by the way, so I can't use it for the following example.] If one Googles Abstract Syntax Tree, one will find exactly what it means. But additionally, one could make a reasonable guess at an approximation of its meaning even without searching.
I think that the "we have a TMA situation" is a nice joke if the right guess is that TMA means "Too Many Acronyms" :) Regards! -- Esteban A. Maringolo
On 5 May 2018 at 02:20, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
On 04/05/2018 13:54, Richard Sargent wrote:
On Fri, May 4, 2018 at 9:45 AM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:
Ramon Leon-5 wrote > And my point made; I don't even know what that means.
Yes. Point made ;)
Ha ha, I googled it and even after seeing the definition still
didn't
understand - we must be getting old ;-)
Also, if one Googles an acronym, such as the recently cited TMA, one gets results like https://en.wikipedia.org/wiki/TMA (a disambiguation page with a lengthy list). [I still don't know which TMA was meant, by the way, so I can't use it for the following example.] If one Googles Abstract Syntax Tree, one will find exactly what it means. But additionally, one could make a reasonable guess at an approximation of its meaning even without searching.
I think that the "we have a TMA situation" is a nice joke if the right guess is that TMA means "Too Many Acronyms" :)
You got it !! cheers -ben
Richard Sargent wrote
No. Please, really no.
As much as I appreciate (and share) the passion for Smalltalk, you did not AFAICT address my reasoning for not applying the no-acronym *guideline* in this case, namely:
Since the argument IIUC is that "a general user won't know the domain well enough to understand the acronym", would they understand "abstractSyntaxTree"?! That, to me, is as opaque as the acronym for one not acquainted with the domain, and may buy us little at the cost of a good amount of extra typing.
Richard Sargent wrote
a disambiguation page with a lengthy list
IMHO this is irrelevant. My proposal included a method comment, which would provide the google-able term, as well as potentially a good enough summary that one wouldn't have to leave the image. The fact that the method belongs to CompiledMethod is the disambiguation. The internet is meaningless and flat compared to the context and structure of a ST image. Richard Sargent wrote
Do not use comments embedded *inside* methods to cover for naming the method badly⦠Also, if one Googles an acronym
How is a harder-to-type thing that the user doesn't understand but is easier to google better than a comment that gives the necessary context right in the image? My ideal image would avoid the need to Google as much as possible, suggesting a comment either way, so nothing lost. There's nothing inherently "bad" about an acronym. For example, no one's been banging down the door to rename "JPEGReadWriter" to "JointPhotographicExpertsGroupReadWriter". In that case, it's because the acronym is so well-known, but what I'm asking whether #ast is a similar candidate for exception because it is so unknown (i.e. compiler domain-specific) that a user is likely to know either the term and the acronym or neither. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On Sat, May 5, 2018 at 3:08 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Richard Sargent wrote
No. Please, really no.
As much as I appreciate (and share) the passion for Smalltalk, you did not AFAICT address my reasoning for not applying the no-acronym *guideline* in this case, namely:
Since the argument IIUC is that "a general user won't know the domain well enough to understand the acronym", would they understand "abstractSyntaxTree"?! That, to me, is as opaque as the acronym for one not acquainted with the domain, and may buy us little at the cost of a good amount of extra typing.
I care a lot less about typing than reading. Some years ago, a colleague of mine conducted a brief and informal survey of the developers working in our team. "What fraction of time do you spend reading code versus writing code?" Some people answered 50:50. In effect, saying that for every method they read, they wrote a new one! The truth is that we all spend substantially more time reading than writing. Consequently, we need to emphasize how we communicate to readers. Alan Knight said it best: (paraphrasing) Trust the implementation does what it says it does. (In other words, message names should do what they say they do without creating the need to look inside the method to understand it.)
Richard Sargent wrote
a disambiguation page with a lengthy list
IMHO this is irrelevant. My proposal included a method comment, which would provide the google-able term, as well as potentially a good enough summary that one wouldn't have to leave the image. The fact that the method belongs to CompiledMethod is the disambiguation. The internet is meaningless and flat compared to the context and structure of a ST image.
Richard Sargent wrote
Do not use comments embedded *inside* methods to cover for naming the method badly⦠Also, if one Googles an acronym
How is a harder-to-type thing that the user doesn't understand but is easier to google better than a comment that gives the necessary context right in the image? My ideal image would avoid the need to Google as much as possible, suggesting a comment either way, so nothing lost. There's nothing inherently "bad" about an acronym. For example, no one's been banging down the door to rename "JPEGReadWriter" to "JointPhotographicExpertsGroupReadWriter". In that case, it's because the acronym is so well-known, but what I'm asking whether #ast is a similar candidate for exception because it is so unknown (i.e. compiler domain-specific) that a user is likely to know either the term and the acronym or neither.
The thing is that a well named concept doesn't need Googling in order to have at least some understanding of its meaning. I would be willing to bet that, even if you had never heard of the topic before, you would have *some* idea what the phrase abstract syntax tree meant. Conversely, the first time one might encounter the concept presented as "ast", you might suspect it was a kind of snake. I'm being a bit extreme here, of course.
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
If you guys are to get rid of acronyms in method names, cosider the following: #onDNU:do: #gcd: #lcm: #rem: #quo: #ulp #ln #theta #r #g #b and others. Then if you get bored again there are a lot of contractions, too, especially in Number and subclasses. Like #abs, #sqrt, #sin, #cos, ... -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
#onDNU:do: That one's not so good. Not so much because of the acronym, but because it's unclear about what the argument is. A better name would be #onUndefinedSelector:do: #gcd: #lcm: These come from elementary (primary school in my day) mathematics. They are the standard names. #rem: #quo: These are not acronyms. They are more intelligible than // and \\. But yes, {floor,ceiling,rounded,truncated}{Quotient,Remainder}: would be clearer. #quo: and #rem: are sufficiently rare that it wouldn't hurt if they were longer. BUT they are in the Blue Book and in the standard. #ulp This is indeed an acronym, and it's probably obscure to many programmers. But practically every paper I have read about floating-point issues uses this; it is a technical term of art. Spelling it out as #unitOfLeastPrecision as VisualWorks does, and as both Squeak and Pharo do in their comments, is the reverse of helpful, because that is not what 'ulp' stands for. It's Unit in the Last Place. Now there IS a case for giving #ulp a long name, but that's not it. There are some subtleties in the definition. http://www.ens-lyon.fr/LIP/Pub/Rapports/RR/RR2005/RR2005-09.pdf lists, by my count, five definitions. The first is obsolete, The fifth is a hybrid of some of the others. It turns out that I knew less about ULPs than I thought I did. #ln #NaperianLogarithm won't help anyone who doesn't know who Napier was or what a logarithm is. I suppose #logarithmToBaseE might work. #theta That is not an acronym. It is spelled out in full. Using Greek letters for arbitrary angles goes back roughly two thousand years. To the Greeks, in fact. Blame them, not Pharo. #r #g #b I can think of at least two meanings for each of these, so granted. Click here to Reply or Forward 0.2 GB (1%) of 15 On 8 May 2018 at 04:57, webwarrior <reg@webwarrior.ws> wrote:
If you guys are to get rid of acronyms in method names, cosider the following:
#onDNU:do: #gcd: #lcm: #rem: #quo: #ulp #ln #theta #r #g #b
and others. Then if you get bored again there are a lot of contractions, too, especially in Number and subclasses. Like #abs, #sqrt, #sin, #cos, ...
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Why to stop there? We could also change our class prefixes. Why to put HTTPSomething when we could put HyperTextTransferProtocolSomething ? :) cheers! Esteban
On 8 May 2018, at 05:15, Richard O'Keefe <raoknz@gmail.com> wrote:
#onDNU:do:
That one's not so good. Not so much because of the acronym, but because it's unclear about what the argument is. A better name would be #onUndefinedSelector:do:
#gcd: #lcm:
These come from elementary (primary school in my day) mathematics. They are the standard names.
#rem: #quo:
These are not acronyms. They are more intelligible than // and \\. But yes, {floor,ceiling,rounded,truncated}{Quotient,Remainder}: would be clearer. #quo: and #rem: are sufficiently rare that it wouldn't hurt if they were longer. BUT they are in the Blue Book and in the standard.
#ulp
This is indeed an acronym, and it's probably obscure to many programmers. But practically every paper I have read about floating-point issues uses this; it is a technical term of art. Spelling it out as #unitOfLeastPrecision as VisualWorks does, and as both Squeak and Pharo do in their comments, is the reverse of helpful, because that is not what 'ulp' stands for. It's Unit in the Last Place. Now there IS a case for giving #ulp a long name, but that's not it. There are some subtleties in the definition. http://www.ens-lyon.fr/LIP/Pub/Rapports/RR/RR2005/RR2005-09.pdf <http://www.ens-lyon.fr/LIP/Pub/Rapports/RR/RR2005/RR2005-09.pdf> lists, by my count, five definitions. The first is obsolete, The fifth is a hybrid of some of the others. It turns out that I knew less about ULPs than I thought I did.
#ln
#NaperianLogarithm won't help anyone who doesn't know who Napier was or what a logarithm is. I suppose #logarithmToBaseE might work.
#theta
That is not an acronym. It is spelled out in full. Using Greek letters for arbitrary angles goes back roughly two thousand years. To the Greeks, in fact. Blame them, not Pharo.
#r #g #b
I can think of at least two meanings for each of these, so granted.
Click here to Reply or Forward 0.2 GB (1%) of 15
On 8 May 2018 at 04:57, webwarrior <reg@webwarrior.ws <mailto:reg@webwarrior.ws>> wrote: If you guys are to get rid of acronyms in method names, cosider the following:
#onDNU:do: #gcd: #lcm: #rem: #quo: #ulp #ln #theta #r #g #b
and others. Then if you get bored again there are a lot of contractions, too, especially in Number and subclasses. Like #abs, #sqrt, #sin, #cos, ...
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html>
Am 08.05.2018 um 05:15 schrieb Richard O'Keefe <raoknz@gmail.com>:
#gcd: #lcm:
These come from elementary (primary school in my day) mathematics. They are the standard names.
You mean where you live? That excludes 90% and more of the world. So when is a abbreviation ok again? Norbert
First, my message was *defending* most of the short names that someone else was attacking. For the record, I am *far* more worried about the fragility of typical Smalltalk code than I am about method names, which are generally pretty good. Second, the criterion was implicit but fairly clear: if an abbreviation of any kind is sufficiently common that someone who wants the semantics will recognise the identifier, use it. "ulp" is MORE familiar to people who need it than "unitOfLeastPrecision" (spit), so it is a better name. In the same way, HTTP is a *better* name than HyperTextWhatever (amongst other things because the word is Hypertext, so HyperText violates a Smalltalk style rule that says internal capitals at *word* boundaries) because it is familiar and takes less effort to recognise than the fully spelled out thing. Third, the rule as always is "intention-revealing names". (Another Smalltalk style rule that I did not invent.) #onDNU:do: is a confusing name because when I saw it I expected the first argument to be a signalled exception, not a selector. There is nothing wrong with the DNU bit; if you know you want to catch a DNU you are probably familiar with "DNU" (and don't want to fuss with whether it means Does Not Understand or Did Not Understand). As a particular example from the list, #log or #logarithm are both ambiguous, while #ln is NOT ambiguous (in the context of numbers), making it a better name, Finally, the significant point was not where I live (about 1/1600 of the world's population live here) but when I went to primary school, which was somewhat more than 50 years ago. Twenty years before that, children learned how to calculate square roots by hand. (Cue Four Yorkshiremen. :-)) On 8 May 2018 at 20:00, Norbert Hartl <norbert@hartl.name> wrote:
Am 08.05.2018 um 05:15 schrieb Richard O'Keefe <raoknz@gmail.com>:
#gcd: #lcm:
These come from elementary (primary school in my day) mathematics. They are the standard names.
You mean where you live? That excludes 90% and more of the world. So when is a abbreviation ok again?
Norbert
to talk seriously, I agree #onDNU:do: would be better called with its long name. now, well known acronyms have their place in pharo as complete, self explaining method names too. is about matter of common sense to opt for one or the other (for example, âln" is more known in maths that its âlong name" neperian logarithm). Rules and conventions are not written in stone and smart people can have an agreement on when to break them. Acronyms is this case: while *in general* using them is bad, well known acronyms as HTTP, AST, etc. are fine and even sometimes better. cheers! Esteban
On 9 May 2018, at 02:03, Richard O'Keefe <raoknz@gmail.com> wrote:
First, my message was *defending* most of the short names that someone else was attacking. For the record, I am *far* more worried about the fragility of typical Smalltalk code than I am about method names, which are generally pretty good.
Second, the criterion was implicit but fairly clear: if an abbreviation of any kind is sufficiently common that someone who wants the semantics will recognise the identifier, use it. "ulp" is MORE familiar to people who need it than "unitOfLeastPrecision" (spit), so it is a better name. In the same way, HTTP is a *better* name than HyperTextWhatever (amongst other things because the word is Hypertext, so HyperText violates a Smalltalk style rule that says internal capitals at *word* boundaries) because it is familiar and takes less effort to recognise than the fully spelled out thing.
Third, the rule as always is "intention-revealing names". (Another Smalltalk style rule that I did not invent.) #onDNU:do: is a confusing name because when I saw it I expected the first argument to be a signalled exception, not a selector. There is nothing wrong with the DNU bit; if you know you want to catch a DNU you are probably familiar with "DNU" (and don't want to fuss with whether it means Does Not Understand or Did Not Understand). As a particular example from the list, #log or #logarithm are both ambiguous, while #ln is NOT ambiguous (in the context of numbers), making it a better name,
Finally, the significant point was not where I live (about 1/1600 of the world's population live here) but when I went to primary school, which was somewhat more than 50 years ago. Twenty years before that, children learned how to calculate square roots by hand. (Cue Four Yorkshiremen. :-))
On 8 May 2018 at 20:00, Norbert Hartl <norbert@hartl.name> wrote:
Am 08.05.2018 um 05:15 schrieb Richard O'Keefe <raoknz@gmail.com>:
#gcd: #lcm:
These come from elementary (primary school in my day) mathematics. They are the standard names.
You mean where you live? That excludes 90% and more of the world. So when is a abbreviation ok again?
Norbert
Richard O'Keefe wrote
First, my message was *defending* most of the short names that someone else was attacking. For the record, I am *far* more worried about the fragility of typical Smalltalk code than I am about method names, which are generally pretty good.
...
If by "someone else" you mean me, I was obviously sarcastic. If you are OK with GCD, LCM, ULP and other abbreviations, why get rid of AST? It's well-known and unambigous term in respective area, that is also usually used as identifier in other programming languages and libraries (e.g. ast module in Python, Microsoft.FSharp.Compiler.Ast module in F#). -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
I'm personally OK with 'ast'. Did I write anything that made you think I wasn't? Of course things are contextual. In VMS one took "AST" to mean "Asynchronous System Trap". But even in VMS it was not confusing in a parsing context. As for "obviously sarcastic", I'm afraid there's this thing called "Poe's Law". On 9 May 2018 at 23:57, webwarrior <reg@webwarrior.ws> wrote:
Richard O'Keefe wrote
First, my message was *defending* most of the short names that someone else was attacking. For the record, I am *far* more worried about the fragility of typical Smalltalk code than I am about method names, which are generally pretty good.
...
If by "someone else" you mean me, I was obviously sarcastic. If you are OK with GCD, LCM, ULP and other abbreviations, why get rid of AST? It's well-known and unambigous term in respective area, that is also usually used as identifier in other programming languages and libraries (e.g. ast module in Python, Microsoft.FSharp.Compiler.Ast module in F#).
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On 05/05/2018 03:08 AM, Sean P. DeNigris wrote:
and may buy us little at the cost of a good amount of extra typing.
Auto-completion killed that argument long ago. Method names are for reading, not writing; the computer will do most of the writing for you. If you're optimizing key strokes when deciding a method name, you're doing it wrong. -- Ramon Leon
2018-05-04 19:45 GMT+03:00 Sean P. DeNigris <sean@clipperadams.com>:
Ramon Leon-5 wrote
And my point made; I don't even know what that means.
Ha ha, I googled it and even after seeing the definition still didn't understand - we must be getting old ;-)
Regarding the use of acronyms - while I agree with you as a general principle, I wonder about this case. Since the argument IIUC is that "a general user won't know the domain well enough to understand the acronym", would they understand "abstractSyntaxTree"?!
Now I am wonder: is it really correct to call syntax tree as abstract when it is really implemented? AST is very known term but now when I read it word by word I have such questions :).
That, to me, is as opaque as the acronym for one not acquainted with the domain, and may buy us little at the cost of a good amount of extra typing. Maybe keep the acronym and add a good method commentâ¦
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2018-05-04 19:45 GMT+03:00 Sean P. DeNigris <sean@clipperadams.com>:
Ramon Leon-5 wrote
And my point made; I don't even know what that means.
Ha ha, I googled it and even after seeing the definition still didn't understand - we must be getting old ;-)
Regarding the use of acronyms - while I agree with you as a general principle, I wonder about this case. Since the argument IIUC is that "a general user won't know the domain well enough to understand the acronym", would they understand "abstractSyntaxTree"?!
Now I am wonder: is it really correct to call syntax tree as abstract when it is really implemented? AST is very known term but now when I read it word by word I have such questions :).
In computer science, an *abstract syntax tree* (AST), or just *syntax tree*, is a *tree* representation of the *abstract syntactic *structure of source code written in a programming language. [Wikipedia]
That, to me, is as opaque as the acronym for one not acquainted with the domain, and may buy us little at the cost of a good amount of extra typing. Maybe keep the acronym and add a good method commentâ¦
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
2018-05-04 21:10 GMT+03:00 Richard Sargent < richard.sargent@gemtalksystems.com>:
On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2018-05-04 19:45 GMT+03:00 Sean P. DeNigris <sean@clipperadams.com>:
Ramon Leon-5 wrote
And my point made; I don't even know what that means.
Ha ha, I googled it and even after seeing the definition still didn't understand - we must be getting old ;-)
Regarding the use of acronyms - while I agree with you as a general principle, I wonder about this case. Since the argument IIUC is that "a general user won't know the domain well enough to understand the acronym", would they understand "abstractSyntaxTree"?!
Now I am wonder: is it really correct to call syntax tree as abstract when it is really implemented? AST is very known term but now when I read it word by word I have such questions :).
In computer science, an *abstract syntax tree* (AST), or just *syntax tree*, is a *tree* representation of the *abstract syntactic *structure of source code written in a programming language. [Wikipedia]
I know it. But my stupid question is why it's still called abstract while it is implemented for concrete language?
That, to me, is as opaque as the acronym for one not acquainted with the domain, and may buy us little at the cost of a good amount of extra typing. Maybe keep the acronym and add a good method commentâ¦
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Le 04/05/2018 à 21:13, Denis Kudriashov a écrit :
2018-05-04 21:10 GMT+03:00 Richard Sargent <richard.sargent@gemtalksystems.com <mailto:richard.sargent@gemtalksystems.com>>:
On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:
2018-05-04 19:45 GMT+03:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>:
Ramon Leon-5 wrote > And my point made; I don't even know what that means.
Ha ha, I googled it and even after seeing the definition still didn't understand - we must be getting old ;-)
Regarding the use of acronyms - while I agree with you as a general principle, I wonder about this case. Since the argument IIUC is that "a general user won't know the domain well enough to understand the acronym", would they understand "abstractSyntaxTree"?!
Now I am wonder: is it really correct to call syntax tree as abstract when it is really implemented? AST is very known term but now when I read it word by word I have such questions :).
In computer science, an*abstract syntax tree*(AST), or just *syntax tree*, is a*tree*representation of the*abstract syntactic *structure of source code written in a programming language. [Wikipedia]
I know it. But my stupid question is why it's still called abstract while it is implemented for concrete language?
This is to make the difference between the parse tree (or concrete syntax tree) and the transformation of that parse tree into an abstract syntax tree (where a bunch of syntax tree nodes created by the parsing are removed or made absent... they are not needed to represent the code structure). Hence the abstract: the abstract syntax tree is an abstraction of the parse tree, even if it represent an exhaustive view of a concrete piece of code. https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/lectures/02/Slide..., slide 159 onward.
That, to me, is as opaque as the acronym for one not acquainted with the domain, and may buy us little at the cost of a good amount of extra typing. Maybe keep the acronym and add a good method commentâ¦
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html>
I know it. But my stupid question is why it's still called abstract while it is implemented for concrete language?
I finally got around to running an image and extracting a screen print. Hopefully, it will attach and be visible to you. The classes of objects in the inspector show the abstract syntax: a method node comprised of a sequence node, etc. Each abstract syntax node is bound with the actual source code that it represents. Abstract is not about the language something is implemented in, but rather the syntactic structure of the code. On Fri, May 4, 2018 at 12:13 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2018-05-04 21:10 GMT+03:00 Richard Sargent <richard.sargent@ gemtalksystems.com>:
On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2018-05-04 19:45 GMT+03:00 Sean P. DeNigris <sean@clipperadams.com>:
Ramon Leon-5 wrote
And my point made; I don't even know what that means.
Ha ha, I googled it and even after seeing the definition still didn't understand - we must be getting old ;-)
Regarding the use of acronyms - while I agree with you as a general principle, I wonder about this case. Since the argument IIUC is that "a general user won't know the domain well enough to understand the acronym", would they understand "abstractSyntaxTree"?!
Now I am wonder: is it really correct to call syntax tree as abstract when it is really implemented? AST is very known term but now when I read it word by word I have such questions :).
In computer science, an *abstract syntax tree* (AST), or just *syntax tree*, is a *tree* representation of the *abstract syntactic *structure of source code written in a programming language. [Wikipedia]
I know it. But my stupid question is why it's still called abstract while it is implemented for concrete language?
That, to me, is as opaque as the acronym for one not acquainted with the domain, and may buy us little at the cost of a good amount of extra typing. Maybe keep the acronym and add a good method commentâ¦
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On 3 May 2018, at 10:56, Tudor Girba <tudor@tudorgirba.com> wrote:
How about: #newAst & #cachedAst?
Best suggestion yet. +1
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-a...
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?"
marcus may be we should slowly deprecated ast into cachedParseTree or something like that. Le 30/4/16 à 22:25, Sean P. DeNigris a écrit :
Why does CompiledMethod understand both? They are in the same protocol, produce the same kindOf result, and neither has a method comment! :/ (Pharo 4.0)
----- Cheers, Sean -- View this message in context: http://forum.world.st/ast-vs-parseTree-tp4893074.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (19)
-
aglynn42＠gmail.com -
Ben Coman -
Bernardo Ezequiel Contreras -
Denis Kudriashov -
Esteban A. Maringolo -
Esteban Lorenzano -
Francisco Garau -
Guillermo Polito -
Marcus Denker -
Norbert Hartl -
Ramon Leon -
Richard O'Keefe -
Richard Sargent -
Sean P. DeNigris -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier -
Tudor Girba -
webwarrior