Re: [Pharo-dev] Pragma keyword / selector / methodSelector

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

Eliot Miranda-2
Hi All,

     can I suggest that Pharo and Squeak coordinate on a change.  First, #selector is bad because it is ambiguous.  As already determined #keyword is awful because it's false (it is a message selector, not just a keyword).  So could we

- use #methodSelector and #pragmaSelector for the next few years, and deprecate #selector and #keyword?

- after a suitable time use #selector to mean #pragmaSelector because that's the most useful abbreviation (in my experience I most often access #pragmaSelector)?

_,,,^..^,,,_ (phone)

> On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <[hidden email]> wrote:
>
> 2016-11-14 11:27 GMT-03:00 [hidden email] <[hidden email]>:
>> Breaking Metacello in Pharo 6: Not good. Revert: +1
>
> Breaking Metacello in any version = Not good.
>
> Metacello is very backward compatible but breaking pragma semantics
> would require a rewrite of many configurations that work okay today
> and would require a new version of Metacello that contemplates the new
> selectors based on some criteria.
>
> Regards!
>
> Esteban A. Maringolo
>

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

Torsten Bergmann
I was hit by this today already as it made Catalog slow like hell (which I fixed):  https://pharo.fogbugz.com/f/cases/19342/.

+1   for the short-term revert
+10  for aligning Squeak and Pharo with a more intention revealing name

Thx
T.

> Gesendet: Montag, 14. November 2016 um 19:49 Uhr
> Von: "Eliot Miranda" <[hidden email]>
> An: "Pharo Development List" <[hidden email]>
> Cc: [hidden email]
> Betreff: Re: [Pharo-dev] Pragma keyword / selector / methodSelector
>
> Hi All,
>
>      can I suggest that Pharo and Squeak coordinate on a change.  First, #selector is bad because it is ambiguous.  As already determined #keyword is awful because it's false (it is a message selector, not just a keyword).  So could we
>
> - use #methodSelector and #pragmaSelector for the next few years, and deprecate #selector and #keyword?
>
> - after a suitable time use #selector to mean #pragmaSelector because that's the most useful abbreviation (in my experience I most often access #pragmaSelector)?
>
> _,,,^..^,,,_ (phone)
>
> > On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <[hidden email]> wrote:
> >
> > 2016-11-14 11:27 GMT-03:00 [hidden email] <[hidden email]>:
> >> Breaking Metacello in Pharo 6: Not good. Revert: +1
> >
> > Breaking Metacello in any version = Not good.
> >
> > Metacello is very backward compatible but breaking pragma semantics
> > would require a rewrite of many configurations that work okay today
> > and would require a new version of Metacello that contemplates the new
> > selectors based on some criteria.
> >
> > Regards!
> >
> > Esteban A. Maringolo
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

Dale Henrichs-3
We are integrating Pragma into the GemStone base for GemStone 3.4.0, so
when the dust settles over the changes I will integrate them into
GemStone 3.4.0 ...

Dale

On 11/14/2016 11:18 AM, Torsten Bergmann wrote:

> I was hit by this today already as it made Catalog slow like hell (which I fixed):  https://pharo.fogbugz.com/f/cases/19342/.
>
> +1   for the short-term revert
> +10  for aligning Squeak and Pharo with a more intention revealing name
>
> Thx
> T.
>
>> Gesendet: Montag, 14. November 2016 um 19:49 Uhr
>> Von: "Eliot Miranda" <[hidden email]>
>> An: "Pharo Development List" <[hidden email]>
>> Cc: [hidden email]
>> Betreff: Re: [Pharo-dev] Pragma keyword / selector / methodSelector
>>
>> Hi All,
>>
>>       can I suggest that Pharo and Squeak coordinate on a change.  First, #selector is bad because it is ambiguous.  As already determined #keyword is awful because it's false (it is a message selector, not just a keyword).  So could we
>>
>> - use #methodSelector and #pragmaSelector for the next few years, and deprecate #selector and #keyword?
>>
>> - after a suitable time use #selector to mean #pragmaSelector because that's the most useful abbreviation (in my experience I most often access #pragmaSelector)?
>>
>> _,,,^..^,,,_ (phone)
>>
>>> On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <[hidden email]> wrote:
>>>
>>> 2016-11-14 11:27 GMT-03:00 [hidden email] <[hidden email]>:
>>>> Breaking Metacello in Pharo 6: Not good. Revert: +1
>>> Breaking Metacello in any version = Not good.
>>>
>>> Metacello is very backward compatible but breaking pragma semantics
>>> would require a rewrite of many configurations that work okay today
>>> and would require a new version of Metacello that contemplates the new
>>> selectors based on some criteria.
>>>
>>> Regards!
>>>
>>> Esteban A. Maringolo
>>>
>>


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

Tobias Pape
Here's my 2ct:

1. Pragmas aren't actually pragmas. They do not instruct the compiler to do things (_except_ for primitive: and apicall:, but these are now  outliers).
   They rather add metadata to a (compiled) method.
2. The 'thing' (ie, class) should probably be named
        MethodAnnotation
3. We can have the cake and eat it to:

        Rename Pragma -> MethodAnnotation.
        Make Pragma a new subclass of MethodAnnotation.
        Make MethodAnnotation implement
                #methodSelector
                #annotationSelector (or #selector, if it must be)
        Make Pragma implement
                #selector
                #keywords

That way, We can nuke Pragma (with its 'old' interface) when the time is right but already us the new variant without introducing problems.

Best regards
        -Tobias

On 15.11.2016, at 20:33, Dale Henrichs <[hidden email]> wrote:

> We are integrating Pragma into the GemStone base for GemStone 3.4.0, so when the dust settles over the changes I will integrate them into GemStone 3.4.0 ...
>
> Dale
>
> On 11/14/2016 11:18 AM, Torsten Bergmann wrote:
>> I was hit by this today already as it made Catalog slow like hell (which I fixed):  https://pharo.fogbugz.com/f/cases/19342/.
>>
>> +1   for the short-term revert
>> +10  for aligning Squeak and Pharo with a more intention revealing name
>>
>> Thx
>> T.
>>
>>> Gesendet: Montag, 14. November 2016 um 19:49 Uhr
>>> Von: "Eliot Miranda" <[hidden email]>
>>> An: "Pharo Development List" <[hidden email]>
>>> Cc: [hidden email]
>>> Betreff: Re: [Pharo-dev] Pragma keyword / selector / methodSelector
>>>
>>> Hi All,
>>>
>>>      can I suggest that Pharo and Squeak coordinate on a change.  First, #selector is bad because it is ambiguous.  As already determined #keyword is awful because it's false (it is a message selector, not just a keyword).  So could we
>>>
>>> - use #methodSelector and #pragmaSelector for the next few years, and deprecate #selector and #keyword?
>>>
>>> - after a suitable time use #selector to mean #pragmaSelector because that's the most useful abbreviation (in my experience I most often access #pragmaSelector)?
>>>
>>> _,,,^..^,,,_ (phone)
>>>
>>>> On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <[hidden email]> wrote:
>>>>
>>>> 2016-11-14 11:27 GMT-03:00 [hidden email] <[hidden email]>:
>>>>> Breaking Metacello in Pharo 6: Not good. Revert: +1
>>>> Breaking Metacello in any version = Not good.
>>>>
>>>> Metacello is very backward compatible but breaking pragma semantics
>>>> would require a rewrite of many configurations that work okay today
>>>> and would require a new version of Metacello that contemplates the new
>>>> selectors based on some criteria.
>>>>
>>>> Regards!
>>>>
>>>> Esteban A. Maringolo
>>>>
>>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

Denis Kudriashov

2016-11-15 21:58 GMT+01:00 Tobias Pape <[hidden email]>:
Here's my 2ct:

1. Pragmas aren't actually pragmas. They do not instruct the compiler to do things (_except_ for primitive: and apicall:, but these are now  outliers).
   They rather add metadata to a (compiled) method.
2. The 'thing' (ie, class) should probably be named
        MethodAnnotation
3. We can have the cake and eat it to:

        Rename Pragma -> MethodAnnotation.
        Make Pragma a new subclass of MethodAnnotation.
        Make MethodAnnotation implement
                #methodSelector
                #annotationSelector (or #selector, if it must be)
        Make Pragma implement
                #selector
                #keywords

I remember long discussion about Pragma vs Annotation name where Igor won completely :)). Conclusion was that Pragma is a right name.


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

Tobias Pape

On 15.11.2016, at 22:08, Denis Kudriashov <[hidden email]> wrote:

>
> 2016-11-15 21:58 GMT+01:00 Tobias Pape <[hidden email]>:
> Here's my 2ct:
>
> 1. Pragmas aren't actually pragmas. They do not instruct the compiler to do things (_except_ for primitive: and apicall:, but these are now  outliers).
>    They rather add metadata to a (compiled) method.
> 2. The 'thing' (ie, class) should probably be named
>         MethodAnnotation
> 3. We can have the cake and eat it to:
>
>         Rename Pragma -> MethodAnnotation.
>         Make Pragma a new subclass of MethodAnnotation.
>         Make MethodAnnotation implement
>                 #methodSelector
>                 #annotationSelector (or #selector, if it must be)
>         Make Pragma implement
>                 #selector
>                 #keywords
>
> I remember long discussion about Pragma vs Annotation name where Igor won completely :)). Conclusion was that Pragma is a right name.

The German wiktionary is more on the compiler-side:

* Pragma: eine Steueranweisung im Quellcode für einen Compiler oder einen Interpreter, die den Programmablauf nicht direkt beeinflusst, die aber Auswirkungen auf bestimmte Überprüfungen des Quellcodes hat

(Control statment for compiler/interpreter that does not directly change control flow but has effect on code checking)…

Sources for this usage:

* „Ein Pragma - auch Pseudo-lnstruktion genannt - leitet einfach Informationen an den Compiler weiter und wird nicht zu einem Teil des ausführbaren Programms.“ [Steven Feuerstein, Bill Pribyl: Oracle PL/SQL Programmierung (Safari Books Online), 2. Auflage 2003, ISBN 389721184X, Seite 85]

(a pragma - aka pseudo instruction - directs simple information to the compiler and _will not be part_ of the executable)  (emphasis mine)

English wiktionary likewise:
        • (computing, programming) A compiler directive; data embedded in source code by programmers to indicate some intention to the compiler.
This pragma stops the compiler from generating those warnings we don't care about.

And also wikipedia:
        https://en.wikipedia.org/wiki/Directive_(programming)



 ¯\_(ツ)_/¯

Best regards
        -Tobias

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

Hannes Hirzel
In reply to this post by Denis Kudriashov
On 11/15/16, Denis Kudriashov <[hidden email]> wrote:

> 2016-11-15 21:58 GMT+01:00 Tobias Pape <[hidden email]>:
>
>> Here's my 2ct:
>>
>> 1. Pragmas aren't actually pragmas. They do not instruct the compiler to
>> do things (_except_ for primitive: and apicall:, but these are now
>> outliers).
>>    They rather add metadata to a (compiled) method.
>> 2. The 'thing' (ie, class) should probably be named
>>         MethodAnnotation
>> 3. We can have the cake and eat it to:
>>
>>         Rename Pragma -> MethodAnnotation.
>>         Make Pragma a new subclass of MethodAnnotation.
>>         Make MethodAnnotation implement
>>                 #methodSelector
>>                 #annotationSelector (or #selector, if it must be)
>>         Make Pragma implement
>>                 #selector
>>                 #keywords
>>
>
> I remember long discussion about Pragma vs Annotation name where Igor won
> completely :)). Conclusion was that Pragma is a right name.

Is there a summary of this discussion available?

--Hannes

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

Denis Kudriashov
You force me to search archives. I hope anybody else does this :).

Here is good answer why pragma instead of annotation: http://forum.world.st/Pragma-support-in-Squeak-Pharo-Cuis-td3243836.html#a3245226

2016-11-16 15:46 GMT+01:00 H. Hirzel <[hidden email]>:
On 11/15/16, Denis Kudriashov <[hidden email]> wrote:
> 2016-11-15 21:58 GMT+01:00 Tobias Pape <[hidden email]>:
>
>> Here's my 2ct:
>>
>> 1. Pragmas aren't actually pragmas. They do not instruct the compiler to
>> do things (_except_ for primitive: and apicall:, but these are now
>> outliers).
>>    They rather add metadata to a (compiled) method.
>> 2. The 'thing' (ie, class) should probably be named
>>         MethodAnnotation
>> 3. We can have the cake and eat it to:
>>
>>         Rename Pragma -> MethodAnnotation.
>>         Make Pragma a new subclass of MethodAnnotation.
>>         Make MethodAnnotation implement
>>                 #methodSelector
>>                 #annotationSelector (or #selector, if it must be)
>>         Make Pragma implement
>>                 #selector
>>                 #keywords
>>
>
> I remember long discussion about Pragma vs Annotation name where Igor won
> completely :)). Conclusion was that Pragma is a right name.

Is there a summary of this discussion available?

--Hannes




Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

Eliot Miranda-2
Hi Tobias, Hi Denis,

On Wed, Nov 16, 2016 at 7:00 AM, Denis Kudriashov <[hidden email]> wrote:
You force me to search archives. I hope anybody else does this :).

Here is good answer why pragma instead of annotation: http://forum.world.st/Pragma-support-in-Squeak-Pharo-Cuis-td3243836.html#a3245226

Thanks.  Igor gets to the technical justification; method annotations/pragmas/those funny things in angle brackets *can* tell a compiler to do things and yes, Tobias, you're right, they *are* also metadata.

The /real/ answer as to why we should use Pragma rather than MethodAnnotation is explained by Wittgenstein; we use words to mean what we want them to mean.  Pragma is now a term that has been used for the Smalltalk scheme for nearly twenty years.  We had a discussion several years ago, even before the thread Denis references, where we agreed that MethodAnnotation was a better name but the effort to make the change was too great for almost all of us (myself included) and so we fell back into using Pragma, and when we write the idea up this year and I presented it at ESUG I went back to using Pragma.  It's shorter, and it means what we want it to mean, which is whatever is between those angle brackets, and whatever we make our compilers to on recognising them.

While the name Pragma may not be a perfect name, it does refer exactly to what we have, and it is short, and it is current.


2016-11-16 15:46 GMT+01:00 H. Hirzel <[hidden email]>:
On 11/15/16, Denis Kudriashov <[hidden email]> wrote:
> 2016-11-15 21:58 GMT+01:00 Tobias Pape <[hidden email]>:
>
>> Here's my 2ct:
>>
>> 1. Pragmas aren't actually pragmas. They do not instruct the compiler to
>> do things (_except_ for primitive: and apicall:, but these are now
>> outliers).
>>    They rather add metadata to a (compiled) method.
>> 2. The 'thing' (ie, class) should probably be named
>>         MethodAnnotation
>> 3. We can have the cake and eat it to:
>>
>>         Rename Pragma -> MethodAnnotation.
>>         Make Pragma a new subclass of MethodAnnotation.
>>         Make MethodAnnotation implement
>>                 #methodSelector
>>                 #annotationSelector (or #selector, if it must be)
>>         Make Pragma implement
>>                 #selector
>>                 #keywords
>>
>
> I remember long discussion about Pragma vs Annotation name where Igor won
> completely :)). Conclusion was that Pragma is a right name.

Is there a summary of this discussion available?

--Hannes








--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

Tobias Pape

On 16.11.2016, at 17:52, Eliot Miranda <[hidden email]> wrote:

> Hi Tobias, Hi Denis,
>
> On Wed, Nov 16, 2016 at 7:00 AM, Denis Kudriashov <[hidden email]> wrote:
> You force me to search archives. I hope anybody else does this :).
>
> Here is good answer why pragma instead of annotation: http://forum.world.st/Pragma-support-in-Squeak-Pharo-Cuis-td3243836.html#a3245226
>
> Thanks.  Igor gets to the technical justification; method annotations/pragmas/those funny things in angle brackets *can* tell a compiler to do things and yes, Tobias, you're right, they *are* also metadata.
>
> The /real/ answer as to why we should use Pragma rather than MethodAnnotation is explained by Wittgenstein; we use words to mean what we want them to mean.  Pragma is now a term that has been used for the Smalltalk scheme for nearly twenty years.  We had a discussion several years ago, even before the thread Denis references, where we agreed that MethodAnnotation was a better name but the effort to make the change was too great for almost all of us (myself included) and so we fell back into using Pragma, and when we write the idea up this year and I presented it at ESUG I went back to using Pragma.  It's shorter, and it means what we want it to mean, which is whatever is between those angle brackets, and whatever we make our compilers to on recognising them.
>
> While the name Pragma may not be a perfect name, it does refer exactly to what we have, and it is short, and it is current.
>

Granted.

But the scheme I proposed would
(a) give us a new, supposedly better fitting interface, while
(b) retaining the established interface under the established name.


Best regards
        -Tobias


>
> 2016-11-16 15:46 GMT+01:00 H. Hirzel <[hidden email]>:
> On 11/15/16, Denis Kudriashov <[hidden email]> wrote:
> > 2016-11-15 21:58 GMT+01:00 Tobias Pape <[hidden email]>:
> >
> >> Here's my 2ct:
> >>
> >> 1. Pragmas aren't actually pragmas. They do not instruct the compiler to
> >> do things (_except_ for primitive: and apicall:, but these are now
> >> outliers).
> >>    They rather add metadata to a (compiled) method.
> >> 2. The 'thing' (ie, class) should probably be named
> >>         MethodAnnotation
> >> 3. We can have the cake and eat it to:
> >>
> >>         Rename Pragma -> MethodAnnotation.
> >>         Make Pragma a new subclass of MethodAnnotation.
> >>         Make MethodAnnotation implement
> >>                 #methodSelector
> >>                 #annotationSelector (or #selector, if it must be)
> >>         Make Pragma implement
> >>                 #selector
> >>                 #keywords
> >>
> >
> > I remember long discussion about Pragma vs Annotation name where Igor won
> > completely :)). Conclusion was that Pragma is a right name.
>
> Is there a summary of this discussion available?
>
> --Hannes
>
>
>
>
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

Levente Uzonyi
In reply to this post by Dale Henrichs-3
Is there a publicly available summary of the Pharo changes and the reasons
behind them?

Levente

On Tue, 15 Nov 2016, Dale Henrichs wrote:

> We are integrating Pragma into the GemStone base for GemStone 3.4.0, so
> when the dust settles over the changes I will integrate them into
> GemStone 3.4.0 ...
>
> Dale
>
> On 11/14/2016 11:18 AM, Torsten Bergmann wrote:
>> I was hit by this today already as it made Catalog slow like hell (which I
> fixed):  https://pharo.fogbugz.com/f/cases/19342/.
>>
>> +1   for the short-term revert
>> +10  for aligning Squeak and Pharo with a more intention revealing name
>>
>> Thx
>> T.
>>
>>> Gesendet: Montag, 14. November 2016 um 19:49 Uhr
>>> Von: "Eliot Miranda" <[hidden email]>
>>> An: "Pharo Development List" <[hidden email]>
>>> Cc: [hidden email]
>>> Betreff: Re: [Pharo-dev] Pragma keyword / selector / methodSelector
>>>
>>> Hi All,
>>>
>>>       can I suggest that Pharo and Squeak coordinate on a change.  First,
> #selector is bad because it is ambiguous.  As already determined #keyword is
> awful because it's false (it is a message selector, not just a keyword).  So
> could we
>>>
>>> - use #methodSelector and #pragmaSelector for the next few years, and
> deprecate #selector and #keyword?
>>>
>>> - after a suitable time use #selector to mean #pragmaSelector because
> that's the most useful abbreviation (in my experience I most often access
> #pragmaSelector)?
>>>
>>> _,,,^..^,,,_ (phone)
>>>
>>>> On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <[hidden email]>
> wrote:
>>>>
>>>> 2016-11-14 11:27 GMT-03:00 [hidden email] <[hidden email]>:
>>>>> Breaking Metacello in Pharo 6: Not good. Revert: +1
>>>> Breaking Metacello in any version = Not good.
>>>>
>>>> Metacello is very backward compatible but breaking pragma semantics
>>>> would require a rewrite of many configurations that work okay today
>>>> and would require a new version of Metacello that contemplates the new
>>>> selectors based on some criteria.
>>>>
>>>> Regards!
>>>>
>>>> Esteban A. Maringolo
>>>>
>>>
>
>
>