Re: [Pharo-users] #ast vs. #parseTree

[Richard O'Keefe]

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

Re: [Pharo-users] #ast vs. #parseTree

[webwarrior]

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

Re: [Pharo-users] #ast vs. #parseTree

[Esteban Lorenzano]

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  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  wrote:
> 
> 
>> Am 08.05.2018 um 05:15 schrieb Richard O'Keefe :
>> 
>> #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
> 
> 

Re: [Pharo-users] #ast vs. #parseTree

[Richard O'Keefe]

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  wrote:

>
>
> Am 08.05.2018 um 05:15 schrieb Richard O'Keefe :
>
> #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
>
>

Re: [Pharo-users] #ast vs. #parseTree

[Norbert Hartl]

> Am 08.05.2018 um 05:15 schrieb Richard O'Keefe :
> 
> #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

Re: [Pharo-users] #ast vs. #parseTree

[Esteban Lorenzano]

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

Re: [Pharo-users] #ast vs. #parseTree

[Richard O'Keefe]

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

Re: [Pharo-users] #ast vs. #parseTree

[webwarrior]

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

Re: [Pharo-users] #ast vs. #parseTree

[Ramon Leon]

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

Re: [Pharo-users] #ast vs. #parseTree

[Richard Sargent]

On Sat, May 5, 2018 at 3:08 AM, Sean P. DeNigris 
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
>
>

Re: [Pharo-users] #ast vs. #parseTree

[Richard Sargent]

>
> 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 
wrote:

>
> 2018-05-04 21:10 GMT+03:00 Richard Sargent  gemtalksystems.com>:
>
>> On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov 
>> wrote:
>>
>>>
>>> 2018-05-04 19:45 GMT+03:00 Sean P. DeNigris :
>>>
 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


>>>
>>
>

Re: [Pharo-users] #ast vs. #parseTree

[Sean P. DeNigris]

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

Re: [Pharo-users] #ast vs. #parseTree

[Thierry Goubier]

Le 04/05/2018 à 21:13, Denis Kudriashov a écrit :


2018-05-04 21:10 GMT+03:00 Richard Sargent 
>:


On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov
> wrote:


2018-05-04 19:45 GMT+03:00 Sean P. DeNigris
>:

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/Slides02.pdf, 
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

Re: [Pharo-users] #ast vs. #parseTree

[Ben Coman]

On 5 May 2018 at 02:20, Esteban A. Maringolo  wrote:

>
> On 04/05/2018 13:54, Richard Sargent wrote:
>
> >> On Fri, May 4, 2018 at 9:45 AM, Sean P. DeNigris  >> > 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

Re: [Pharo-users] #ast vs. #parseTree

[aglynn42]

Just as TLA is a three letter acronym ... 

-Original Message-
From: Pharo-users <pharo-users-boun...@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.sarg...@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 
>> <s...@clipperadams.com <mailto:s...@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

Re: [Pharo-users] #ast vs. #parseTree

[Denis Kudriashov]

2018-05-04 21:10 GMT+03:00 Richard Sargent <
richard.sarg...@gemtalksystems.com>:

> On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov 
> wrote:
>
>>
>> 2018-05-04 19:45 GMT+03:00 Sean P. DeNigris :
>>
>>> 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
>>>
>>>
>>
>

Re: [Pharo-users] #ast vs. #parseTree

[Esteban A. Maringolo]

On 04/05/2018 13:54, Richard Sargent wrote:

>> On Fri, May 4, 2018 at 9:45 AM, Sean P. DeNigris > > 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

Re: [Pharo-users] #ast vs. #parseTree

[Richard Sargent]

On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov 
wrote:

>
> 2018-05-04 19:45 GMT+03:00 Sean P. DeNigris :
>
>> 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
>>
>>
>

Re: [Pharo-users] #ast vs. #parseTree

[Denis Kudriashov]

2018-05-04 19:45 GMT+03:00 Sean P. DeNigris :

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

Re: [Pharo-users] #ast vs. #parseTree

[Richard Sargent]

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

Re: [Pharo-users] #ast vs. #parseTree

[Sean P. DeNigris]

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

Re: [Pharo-users] #ast vs. #parseTree

[Ramon Leon]

On 05/04/2018 01:29 AM, Ben Coman wrote:

a TMA situation?


And my point made; I don't even know what that means.

--
Ramon Leon

Re: [Pharo-users] #ast vs. #parseTree

[Ben Coman]

On 4 May 2018 at 08:02, Ramon Leon  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?

Re: [Pharo-users] #ast vs. #parseTree

[Sven Van Caekenberghe]

> On 3 May 2018, at 10:56, Tudor Girba  wrote:
> 
> How about: #newAst & #cachedAst?

Best suggestion yet. +1

> Cheers,
> Doru
> 
> 
>> On May 3, 2018, at 9:30 AM, Guillermo Polito  
>> wrote:
>> 
>> method newAst ?
>> 
>> On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras 
>>  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 
>>  wrote:
>> On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov  
>> 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 :
>> 
>> 
>>> On 27 Apr 2018, at 21:36, Sean P. DeNigris  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?"
> 
> 

Re: [Pharo-users] #ast vs. #parseTree

[Ramon Leon]

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

Re: [Pharo-users] #ast vs. #parseTree

[Francisco Garau]

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  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  a 
>> écrit :
>> +1 to avoid acronyms.
>> 
>> Esteban A. Maringolo
>> 
>> 2018-05-03 12:47 GMT-03:00 Francisco Garau :
>>> 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

Re: [Pharo-users] #ast vs. #parseTree

[Guillermo Polito]

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  a
écrit :

> +1 to avoid acronyms.
>
> Esteban A. Maringolo
>
> 2018-05-03 12:47 GMT-03:00 Francisco Garau :
>
>> 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

Re: [Pharo-users] #ast vs. #parseTree

[Esteban A. Maringolo]

+1 to avoid acronyms.

Esteban A. Maringolo

2018-05-03 12:47 GMT-03:00 Francisco Garau :

> I'd rather be also explicit in the name and avoid acronyms.
> #newAbstractSyntaxTree and #cachedAbstractSyntaxTree
>
> - Francisco
>
>
>

Re: [Pharo-users] #ast vs. #parseTree

[Francisco Garau]

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  wrote:
> 
> Ahh explicitness :)
> 
>> On Thu, May 3, 2018 at 10:56 AM, Tudor Girba  wrote:
>> How about: #newAst & #cachedAst?
>> 
>> Cheers,
>> Doru
>> 
>> 
>> > On May 3, 2018, at 9:30 AM, Guillermo Polito  
>> > wrote:
>> > 
>> > method newAst ?
>> > 
>> > On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras 
>> >  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 
>> >  wrote:
>> > On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov  
>> > 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 :
>> > 
>> > 
>> > > On 27 Apr 2018, at 21:36, Sean P. DeNigris  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

Re: [Pharo-users] #ast vs. #parseTree

[Sean P. DeNigris]

Guillermo Polito wrote
> Ahh explicitness :)

+1!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] #ast vs. #parseTree

[Guillermo Polito]

Ahh explicitness :)

On Thu, May 3, 2018 at 10:56 AM, Tudor Girba  wrote:

> How about: #newAst & #cachedAst?
>
> Cheers,
> Doru
>
>
> > On May 3, 2018, at 9:30 AM, Guillermo Polito 
> 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  gemtalksystems.com> wrote:
> > On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov 
> 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 :
> >
> >
> > > On 27 Apr 2018, at 21:36, Sean P. DeNigris 
> 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

Re: [Pharo-users] #ast vs. #parseTree

[Tudor Girba]

How about: #newAst & #cachedAst?

Cheers,
Doru


> On May 3, 2018, at 9:30 AM, Guillermo Polito  
> wrote:
> 
> method newAst ?
> 
> On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras 
>  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 
>  wrote:
> On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov  
> 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 :
> 
> 
> > On 27 Apr 2018, at 21:36, Sean P. DeNigris  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?"

Re: [Pharo-users] #ast vs. #parseTree

[Guillermo Polito]

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  gemtalksystems.com> wrote:
>
>> On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov 
>> 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 :
>>>


 > On 27 Apr 2018, at 21:36, Sean P. DeNigris 
 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
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] #ast vs. #parseTree

[Bernardo Ezequiel Contreras]

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 
> 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 :
>>
>>>
>>>
>>> > On 27 Apr 2018, at 21:36, Sean P. DeNigris 
>>> 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.

Re: [Pharo-users] #ast vs. #parseTree

[Richard Sargent]

On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov 
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 :
>
>>
>>
>> > On 27 Apr 2018, at 21:36, Sean P. DeNigris 
>> 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
>>
>
>

Re: [Pharo-users] #ast vs. #parseTree

[Denis Kudriashov]

Hi.

Maybe #parseSourceCode would be better name for #parseTree.

2018-05-02 16:33 GMT+03:00 Marcus Denker :

>
>
> > On 27 Apr 2018, at 21:36, Sean P. DeNigris 
> 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
>

Re: [Pharo-users] #ast vs. #parseTree

[Marcus Denker]

> On 2 May 2018, at 17:34, Sean P. DeNigris  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 

Re: [Pharo-users] #ast vs. #parseTree

[Sean P. DeNigris]

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

Re: [Pharo-users] #ast vs. #parseTree

[Marcus Denker]

> On 27 Apr 2018, at 21:36, Sean P. DeNigris  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

Re: [Pharo-users] #ast vs. #parseTree

[Sean P. DeNigris]

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

Re: [Pharo-users] #ast vs. #parseTree

[Marcus Denker]

> On 01 May 2016, at 14:45, Sean P. DeNigris  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

Re: [Pharo-users] #ast vs. #parseTree

[stepharo]

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.

Re: [Pharo-users] #ast vs. #parseTree

[Sean P. DeNigris]

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.

Re: [Pharo-users] #ast vs. #parseTree

[Marcus Denker]

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

[Pharo-users] #ast vs. #parseTree

[Sean P. DeNigris]

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.