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 > |
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 > > > > |
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 >>> >> |
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 >>>> >>> > > |
2016-11-15 21:58 GMT+01:00 Tobias Pape <[hidden email]>:
I remember long discussion about Pragma vs Annotation name where Igor won completely :)). Conclusion was that Pragma is a right name. |
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 |
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 |
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]>:
|
Hi Tobias, Hi Denis,
On Wed, Nov 16, 2016 at 7:00 AM, Denis Kudriashov <[hidden email]> wrote:
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.
_,,,^..^,,,_ best, Eliot |
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 |
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 >>>> >>> > > > |
Free forum by Nabble | Edit this page |