Smalltalk › Pharo › Pharo Smalltalk Users

#ast vs. #parseTree

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

45 messages Options

123

Ramon Leon-5

Re: #ast vs. #parseTree

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

Sven Van Caekenberghe-2

Re: #ast vs. #parseTree

In reply to this post by Tudor Girba-2

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

Best suggestion yet. +1

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

Ben Coman

Re: #ast vs. #parseTree

In reply to this post by Ramon Leon-5

On 4 May 2018 at 08:02, Ramon Leon <[hidden email]> 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

Re: #ast vs. #parseTree

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

Sean P. DeNigris

Re: #ast vs. #parseTree

Administrator

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

Cheers,
Sean

Richard Sargent

Re: #ast vs. #parseTree

Administrator

"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 <[hidden email]> 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

Denis Kudriashov

Re: #ast vs. #parseTree

In reply to this post by Sean P. DeNigris

2018-05-04 19:45 GMT+03:00 Sean P. DeNigris <[hidden email]>:

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

Richard Sargent

Re: #ast vs. #parseTree

Administrator

On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov <[hidden email]> wrote:

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

Esteban A. Maringolo

Re: #ast vs. #parseTree

In reply to this post by Richard Sargent

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

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

Denis Kudriashov

Re: #ast vs. #parseTree

In reply to this post by Richard Sargent

2018-05-04 21:10 GMT+03:00 Richard Sargent <[hidden email]>:

On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov <[hidden email]> wrote:

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

aglynn42

Re: #ast vs. #parseTree

In reply to this post by Esteban A. Maringolo

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

-----Original Message-----
From: Pharo-users <[hidden email]> On Behalf Of Esteban A. Maringolo
Sent: Friday, May 4, 2018 2:21 PM
To: Any question about pharo is welcome <[hidden email]>; Richard Sargent <[hidden email]>
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
>> <[hidden email] <mailto:[hidden email]>> 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

Ben Coman

Re: #ast vs. #parseTree

In reply to this post by Esteban A. Maringolo

On 5 May 2018 at 02:20, Esteban A. Maringolo <[hidden email]> wrote:

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

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

Thierry Goubier

Re: #ast vs. #parseTree

In reply to this post by Denis Kudriashov

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

>
> 2018-05-04 21:10 GMT+03:00 Richard Sargent
> <[hidden email]
> <mailto:[hidden email]>>:
>
> On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>
> 2018-05-04 19:45 GMT+03:00 Sean P. DeNigris
> <[hidden email] <mailto:[hidden email]>>:
>
> 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
> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html>
>
>
>
>

Sean P. DeNigris

Re: #ast vs. #parseTree

Administrator

In reply to this post by Richard Sargent

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

Cheers,
Sean

Richard Sargent

Re: #ast vs. #parseTree

Administrator

In reply to this post by Denis Kudriashov

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 <[hidden email]> wrote:

2018-05-04 21:10 GMT+03:00 Richard Sargent <[hidden email]>:
On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov <[hidden email]> wrote:

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

abstractsyntaxtree.png (88K) Download Attachment

Richard Sargent

Re: #ast vs. #parseTree

Administrator

In reply to this post by Sean P. DeNigris

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

Ramon Leon-5

Re: #ast vs. #parseTree

In reply to this post by Sean P. DeNigris

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

webwarrior

Re: #ast vs. #parseTree

In reply to this post by Richard Sargent

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

Richard O'Keefe

Re: #ast vs. #parseTree

#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 <[hidden email]> 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

EstebanLM

Re: #ast vs. #parseTree

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 <[hidden email]> 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 <[hidden email]> 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

123