Pragma support in Squeak/Pharo/Cuis

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

Pragma support in Squeak/Pharo/Cuis

Torsten Bergmann
Hi,

I would like to port the recent changes made to HelpSystem
(for instance to be able to mark a method with a pragma
 like <wikiStyleHelp: 'My Book'>)

This would allow to define and load help contents without
any dependency on the help system.

Unfortunately Squeak now differs (a little bit?) from Pharo
regarding the Pragma support. There is no PragmaCollector class, ...
Dont know if there are more differences, any ideas/experiences?
What about Cuis?

Would'nt it make sense to use a similar implementation in
all worlds?

Comments appreciated.

Thx
T.






--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Tobias Pape
Am 2011-01-28 um 08:19 schrieb Torsten Bergmann:

> Hi,
>
> I would like to port the recent changes made to HelpSystem
> (for instance to be able to mark a method with a pragma
> like <wikiStyleHelp: 'My Book'>)
>
> This would allow to define and load help contents without
> any dependency on the help system.
>
> Unfortunately Squeak now differs (a little bit?) from Pharo
> regarding the Pragma support. There is no PragmaCollector class, ...
> Dont know if there are more differences, any ideas/experiences?
> What about Cuis?


What is that PragmaCollector for?
What does it provide over the 'finding' methods in Pragma class?
(eg allNamed:in: allNamed:from:in etc.pp.)

So Long
        -Tobias

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Juan Vuletich-4
In reply to this post by Torsten Bergmann
Torsten Bergmann wrote:

> Hi,
>
> I would like to port the recent changes made to HelpSystem
> (for instance to be able to mark a method with a pragma
>  like <wikiStyleHelp: 'My Book'>)
>
> This would allow to define and load help contents without
> any dependency on the help system.
>
> Unfortunately Squeak now differs (a little bit?) from Pharo
> regarding the Pragma support. There is no PragmaCollector class, ...
> Dont know if there are more differences, any ideas/experiences?
> What about Cuis?
>
> Would'nt it make sense to use a similar implementation in
> all worlds?
>
> Comments appreciated.
>
> Thx
> T.

Hi Torsten,

You mean "method annotations" right? ('Pragma' has a completely
different meaning in the language / compilers that use them, and is a
very bad name for this).

Cuis doesn't currently support method annotations.

Cheers,
Juan Vuletich

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Igor Stasenko
On 28 January 2011 13:59, Juan Vuletich <[hidden email]> wrote:

> Torsten Bergmann wrote:
>>
>> Hi,
>>
>> I would like to port the recent changes made to HelpSystem
>> (for instance to be able to mark a method with a pragma
>>  like <wikiStyleHelp: 'My Book'>)
>> This would allow to define and load help contents without any dependency
>> on the help system.
>>
>> Unfortunately Squeak now differs (a little bit?) from Pharo regarding the
>> Pragma support. There is no PragmaCollector class, ...
>> Dont know if there are more differences, any ideas/experiences?
>> What about Cuis?
>>
>> Would'nt it make sense to use a similar implementation in all worlds?
>> Comments appreciated.
>> Thx
>> T.
>
> Hi Torsten,
>
> You mean "method annotations" right? ('Pragma' has a completely different
> meaning in the language / compilers that use them, and is a very bad name
> for this).
>
Is this sarcasm? yeah?
This naming used for years, and now it became not simple bad, but
_very_ bad name :)

> Cuis doesn't currently support method annotations.
>

huh... how then you specifying a primitive(s) in method? and FFI?
or in same way you can say.. yeah this is not pragma , its a primitive..
but it doesn't makes any difference.

You may call it  'a method's meta-data' or any other way you like it,
i _dont_ care!
As long as the idea behind is will remain same.


> Cheers,
> Juan Vuletich
>


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Andreas.Raab
On 1/28/2011 2:07 PM, Igor Stasenko wrote:
> On 28 January 2011 13:59, Juan Vuletich<[hidden email]>  wrote:
>> You mean "method annotations" right? ('Pragma' has a completely different
>> meaning in the language / compilers that use them, and is a very bad name
>> for this).
>>
> Is this sarcasm? yeah?
> This naming used for years, and now it became not simple bad, but
> _very_ bad name :)

Hardly. Juan is absolutely right that a pragma is a _very_ bad name,
something very specific, namely an instruction to the compiler to do
something. Therefore, all pragmas are annotations but not all
annotations are pragmas. For example <primitive: 123> is a pragma (it
instructs the compiler to generate a primitive) but <hello: 'world'> is not.

>> Cuis doesn't currently support method annotations.
>>
>
> huh... how then you specifying a primitive(s) in method? and FFI?
> or in same way you can say.. yeah this is not pragma , its a primitive..
> but it doesn't makes any difference.

It does. Juan is exactly right, Cuis supports pragmas (<primitive:> or
FFI calls) but not annotations.

> You may call it  'a method's meta-data' or any other way you like it,
> i _dont_ care!
> As long as the idea behind is will remain same.

But the idea _isn't_ the same. The idea of pragmas is to instruct the
compiler to do something specific. The idea of method annotations is to
provide additional information in methods that isn't executable.

In other words: Pragmas are "understood" by the compiler, method
annotations are not.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Juan Vuletich-4
In reply to this post by Igor Stasenko
Igor Stasenko wrote:

> On 28 January 2011 13:59, Juan Vuletich <[hidden email]> wrote:
>  
>> Torsten Bergmann wrote:
>>    
>>> Hi,
>>>
>>> I would like to port the recent changes made to HelpSystem
>>> (for instance to be able to mark a method with a pragma
>>>  like <wikiStyleHelp: 'My Book'>)
>>> This would allow to define and load help contents without any dependency
>>>      
>
>  
>>> on the help system.
>>>
>>> Unfortunately Squeak now differs (a little bit?) from Pharo regarding the
>>> Pragma support. There is no PragmaCollector class, ...
>>> Dont know if there are more differences, any ideas/experiences?
>>> What about Cuis?
>>>
>>> Would'nt it make sense to use a similar implementation in all worlds?
>>> Comments appreciated.
>>> Thx
>>> T.
>>>      
>> Hi Torsten,
>>
>> You mean "method annotations" right? ('Pragma' has a completely different
>> meaning in the language / compilers that use them, and is a very bad name
>>    
>
>  
>> for this).
>>
>>    
> Is this sarcasm? yeah?
>  

Not at all.

> This naming used for years, and now it became not simple bad, but
> _very_ bad name :)
>  

A pragma is a directive to the compiler to control some detail of the
code generation. Method annotations are not pragmas. Calling them
'pragmas' is misleading. This has already been discussed here. I believe
the outcome of that discussion was that "method annotations" was the
correct name.

>> Cuis doesn't currently support method annotations.
>>
>>    
>
> huh... how then you specifying a primitive(s) in method? and FFI?
> or in same way you can say.. yeah this is not pragma , its a primitive..
> but it doesn't makes any difference.
>
> You may call it  'a method's meta-data' or any other way you like it,
> i _dont_ care!
> As long as the idea behind is will remain same.
>  

I was wrong, apologies. Cuis does support method annotations, I just
forgot I had integrated that code.

Side note: Squeak and ST-80 had primitives using the <primitive: nn>
syntax long before anyone thought about adding "pragmas" "method
annotations" or whatever. Besides, primitive and ffi calls are neither
pragmas nor method annotations nor meta-data. They are a syntax for the
compiler to generate executable code, i.e. they are source code. Calling
them 'pragmas' or 'meta-data' is mixing two different concepts.

Unfortunately, the code calls it 'pragma' everywhere. It seems the name
'pragma' is here to stay. So, when someone comes from another
programming language we'll have to explain "The word 'pragma' sometimes
means a kind of procedure call (primitives, ffi), and sometimes it means
'method annotation' or 'method metadata'; but it never means 'compiler
directive' to us" ...sigh...

Cheers,
Juan Vuletich

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Chris Cunnington
In reply to this post by Torsten Bergmann
 >Method annotations are not pragmas.

It might be easier to say that method annotations never had a class to
identify them with before Lukas created class
Pragma in 2006.

Chris

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Andreas.Raab
On 1/28/2011 3:40 PM, Chris Cunnington wrote:
>  >Method annotations are not pragmas.
>
> It might be easier to say that method annotations never had a class to
> identify them with before Lukas created class
> Pragma in 2006.

Unfortunately, that neither changes the statement nor does it make the
name any better :) (and fwiw, I am in favor of Travis' "method tag"
terminology)

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Casey Ransberger-2
In reply to this post by Juan Vuletich-4
I think it's worth actually changing the term in the code. If Squeak has educational value, we shouldn't use a misnomer like that. Anyway, I expected "pragma" to mean what it meant in other systems and it confused the hell out of me.

I do not, however, understand that part of the system well enough to doIt.

On Jan 28, 2011, at 6:27 AM, Juan Vuletich <[hidden email]> wrote:

> Igor Stasenko wrote:
>> On 28 January 2011 13:59, Juan Vuletich <[hidden email]> wrote:
>>  
>>> Torsten Bergmann wrote:
>>>    
>>>> Hi,
>>>>
>>>> I would like to port the recent changes made to HelpSystem
>>>> (for instance to be able to mark a method with a pragma
>>>> like <wikiStyleHelp: 'My Book'>)
>>>> This would allow to define and load help contents without any dependency
>>>>      
>>
>>  
>>>> on the help system.
>>>>
>>>> Unfortunately Squeak now differs (a little bit?) from Pharo regarding the
>>>> Pragma support. There is no PragmaCollector class, ...
>>>> Dont know if there are more differences, any ideas/experiences?
>>>> What about Cuis?
>>>>
>>>> Would'nt it make sense to use a similar implementation in all worlds?
>>>> Comments appreciated.
>>>> Thx
>>>> T.
>>>>      
>>> Hi Torsten,
>>>
>>> You mean "method annotations" right? ('Pragma' has a completely different
>>> meaning in the language / compilers that use them, and is a very bad name
>>>    
>>
>>  
>>> for this).
>>>
>>>    
>> Is this sarcasm? yeah?
>>  
>
> Not at all.
>
>> This naming used for years, and now it became not simple bad, but
>> _very_ bad name :)
>>  
>
> A pragma is a directive to the compiler to control some detail of the code generation. Method annotations are not pragmas. Calling them 'pragmas' is misleading. This has already been discussed here. I believe the outcome of that discussion was that "method annotations" was the correct name.
>
>>> Cuis doesn't currently support method annotations.
>>>
>>>    
>>
>> huh... how then you specifying a primitive(s) in method? and FFI?
>> or in same way you can say.. yeah this is not pragma , its a primitive..
>> but it doesn't makes any difference.
>>
>> You may call it  'a method's meta-data' or any other way you like it,
>> i _dont_ care!
>> As long as the idea behind is will remain same.
>>  
>
> I was wrong, apologies. Cuis does support method annotations, I just forgot I had integrated that code.
>
> Side note: Squeak and ST-80 had primitives using the <primitive: nn> syntax long before anyone thought about adding "pragmas" "method annotations" or whatever. Besides, primitive and ffi calls are neither pragmas nor method annotations nor meta-data. They are a syntax for the compiler to generate executable code, i.e. they are source code. Calling them 'pragmas' or 'meta-data' is mixing two different concepts.
>
> Unfortunately, the code calls it 'pragma' everywhere. It seems the name 'pragma' is here to stay. So, when someone comes from another programming language we'll have to explain "The word 'pragma' sometimes means a kind of procedure call (primitives, ffi), and sometimes it means 'method annotation' or 'method metadata'; but it never means 'compiler directive' to us" ...sigh...
>
> Cheers,
> Juan Vuletich
>

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Casey Ransberger-2
In reply to this post by Andreas.Raab
+1

It looks like an XML tag. This language is most intuitive to me FWIW.

On Jan 28, 2011, at 7:00 AM, Andreas Raab <[hidden email]> wrote:

> On 1/28/2011 3:40 PM, Chris Cunnington wrote:
>> >Method annotations are not pragmas.
>>
>> It might be easier to say that method annotations never had a class to
>> identify them with before Lukas created class
>> Pragma in 2006.
>
> Unfortunately, that neither changes the statement nor does it make the name any better :) (and fwiw, I am in favor of Travis' "method tag" terminology)
>
> Cheers,
>  - Andreas
>

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Igor Stasenko
In reply to this post by Andreas.Raab
On 28 January 2011 15:21, Andreas Raab <[hidden email]> wrote:

> On 1/28/2011 2:07 PM, Igor Stasenko wrote:
>>
>> On 28 January 2011 13:59, Juan Vuletich<[hidden email]>  wrote:
>>>
>>> You mean "method annotations" right? ('Pragma' has a completely different
>>> meaning in the language / compilers that use them, and is a very bad name
>>> for this).
>>>
>> Is this sarcasm? yeah?
>> This naming used for years, and now it became not simple bad, but
>> _very_ bad name :)
>
> Hardly. Juan is absolutely right that a pragma is a _very_ bad name,
> something very specific, namely an instruction to the compiler to do
> something.

Anything which included in source code is "an instruction to the
compiler to do something", otherwise there is no reason and no sense
of putting it there.
The difference lies in the who and what exactly "something" it should do.
Since pragmas and annotations having same context and same syntax ,
except that they differ
in "do something" part, there is not much difference in reality,
especially if you take into account a reflective nature
of smalltalk system, where tools can observe the various properties of
objects (such as compiled methods) and
decide what to do based of their behavior/state/whatever.

So, even if <something> doesn't looks like a pragma (an instruction)
for you or your compiler,
it could mean a lot for other tools. Does that makes it to be less
'pragmatic' just because its not instruction to compiler but to
some other  tool? I don't think so.
The <wikiStyleHelp: 'My Book'>  is a help system pragma and don't try
to convince me otherwise.

> Therefore, all pragmas are annotations but not all annotations
> are pragmas. For example <primitive: 123> is a pragma (it instructs the
> compiler to generate a primitive) but <hello: 'world'> is not.
>
and, if at some moment in future it will change compiler to react on <hello:>,
then it magically turn to be the pragma? So, why i can't call it like
that right now?
Because of bad name? :)

>>> Cuis doesn't currently support method annotations.
>>>
>>
>> huh... how then you specifying a primitive(s) in method? and FFI?
>> or in same way you can say.. yeah this is not pragma , its a primitive..
>> but it doesn't makes any difference.
>
> It does. Juan is exactly right, Cuis supports pragmas (<primitive:> or FFI
> calls) but not annotations.
>
>> You may call it  'a method's meta-data' or any other way you like it,
>> i _dont_ care!
>> As long as the idea behind is will remain same.
>
> But the idea _isn't_ the same. The idea of pragmas is to instruct the
> compiler to do something specific. The idea of method annotations is to
> provide additional information in methods that isn't executable.
>

No. The idea behind it the same. Instruct some tool to do something
once it detects the pragma.
Take Cog VMMaker for instance.
Its generator using <api> pragmas for determining if method represents
a public function, which should be
publicly declared. And you probably know that there are many other
pragmas used in code generation.
Your problem is that you narrowing the 'pragma' functionality to one
tool - compiler. While i see that it is used by many many different
tools.
So, why calling it pragma when applied to compiler, but annotation
when applied to other tools? Don't makes much sense as to me.

In contrast, Annotations (or tags) are not instructing any tools to
behave differently. Pragmas do. And therefore annotations - (minus)
pragmas
are worthless, because then the only purpose of annotations would be
to be found by human who will wonder "why this method having this
<foo> thing??..
This concept doesn't sounds like pragmatic and don't having any
practical purpose, unless you write some tool which makes use of your
'annotations',
but then these annotations are immediately turned into pragmas,
because they turned to be some kind of instruction for you tool to do
something.

So, annotations is worthless thing for computing, because it makes
difference only to people, not to behavior of our tools because tools
use pragmas. :)


> In other words: Pragmas are "understood" by the compiler, method annotations
> are not.
>
> Cheers,
>  - Andreas
>


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Eliot Miranda-2
In reply to this post by Casey Ransberger-2


On Fri, Jan 28, 2011 at 10:38 AM, Casey Ransberger <[hidden email]> wrote:
+1

It looks like an XML tag. This language is most intuitive to me FWIW.

But it isn't.  It is a message pattern with literal arguments (a message with literal arguments and no receiver).  It has nothing to do with XML.  Having it as a message pattern means:
- one can search for references to the method tag by searching for senders of the message tag's selector
- one can provide implementation(s) of the selector and hence execute the method tag using perform

Hence method tags are better integrated in Smalltalk than in other languages; one can do meta-programming with them.  They're not merely annotations, they're executable annotations.  IMO the coolest uses of method tags are those that trigger some evaluation of the method tags by some method tag processor when methods containing method tags are either added or removed (compiled/deleted) from the system such as automatically adding an entry to a system menu when a method defining an action to be dispatched from the menu is added with a method tag that references the menu.  Using this approach one has to perform one action (compiling a method) not two (compiling the action method and modifying/compiling the menu definition method).

best
Eliot


On Jan 28, 2011, at 7:00 AM, Andreas Raab <[hidden email]> wrote:

> On 1/28/2011 3:40 PM, Chris Cunnington wrote:
>> >Method annotations are not pragmas.
>>
>> It might be easier to say that method annotations never had a class to
>> identify them with before Lukas created class
>> Pragma in 2006.
>
> Unfortunately, that neither changes the statement nor does it make the name any better :) (and fwiw, I am in favor of Travis' "method tag" terminology)
>
> Cheers,
>  - Andreas
>




Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Juan Vuletich-4
In reply to this post by Igor Stasenko
Igor Stasenko wrote:

>
> Anything which included in source code is "an instruction to the
> compiler to do something", otherwise there is no reason and no sense
> of putting it there.
> The difference lies in the who and what exactly "something" it should do.
> Since pragmas and annotations having same context and same syntax ,
> except that they differ
> in "do something" part, there is not much difference in reality,
> especially if you take into account a reflective nature
> of smalltalk system, where tools can observe the various properties of
> objects (such as compiled methods) and
> decide what to do based of their behavior/state/whatever.
>
> So, even if <something> doesn't looks like a pragma (an instruction)
> for you or your compiler,
> it could mean a lot for other tools. Does that makes it to be less
> 'pragmatic' just because its not instruction to compiler but to
> some other  tool? I don't think so.
> The <wikiStyleHelp: 'My Book'>  is a help system pragma and don't try
> to convince me otherwise.
>  

This is waaay off deserving a real answer.

Cheers,
Juan Vuletich

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Igor Stasenko
On 28 January 2011 21:00, Juan Vuletich <[hidden email]> wrote:

> Igor Stasenko wrote:
>>
>> Anything which included in source code is "an instruction to the
>> compiler to do something", otherwise there is no reason and no sense
>> of putting it there.
>> The difference lies in the who and what exactly "something" it should do.
>> Since pragmas and annotations having same context and same syntax ,
>> except that they differ
>> in "do something" part, there is not much difference in reality,
>> especially if you take into account a reflective nature
>> of smalltalk system, where tools can observe the various properties of
>> objects (such as compiled methods) and
>> decide what to do based of their behavior/state/whatever.
>>
>> So, even if <something> doesn't looks like a pragma (an instruction)
>> for you or your compiler,
>> it could mean a lot for other tools. Does that makes it to be less
>> 'pragmatic' just because its not instruction to compiler but to
>> some other  tool? I don't think so.
>> The <wikiStyleHelp: 'My Book'>  is a help system pragma and don't try
>> to convince me otherwise.
>>
>
> This is waaay off deserving a real answer.
>
:)

yeah.. we are discussing about using proper wording instead of helping
Torsten with his issue.


> Cheers,
> Juan Vuletich
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Chris Cunnington
In reply to this post by Torsten Bergmann
I've got some notes from 2 May 2010 about pragmas. Eliot produced this example at the time:

        x := Editor class compiledMethodAt: #blinkingCursor.
       
        x pragmas
{<preference: 'Blinking Text Cursor' category: 'Morphic' description: 'When true, the text cursor will blink.' type: #Boolean>}.
       
I think that corresponds with his message today:

>  Having it as a message pattern means:
>- one can search for references to the method tag by searching for senders
>of the message tag's selector

But the ultimate destination of all method annotations is a #perform:?
I take that from this:

>- one can provide implementation(s) of the selector and hence execute the
>method tag using perform

So the ultimate destination of all pragmas/method annotations/method tags is that somewhere a #perform: lurks waiting
for it? Sometimes that's the Compiler class and sometimes it's another class with a #perform:.

I'd appreciate it if somebody could say if this is an accurate picture.
A "yes" will do it.

Chris


Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Eliot Miranda-2


On Fri, Jan 28, 2011 at 1:39 PM, Chris Cunnington <[hidden email]> wrote:
I've got some notes from 2 May 2010 about pragmas. Eliot produced this example at the time:

       x := Editor class compiledMethodAt: #blinkingCursor.
       
       x pragmas
{<preference: 'Blinking Text Cursor' category: 'Morphic' description: 'When true, the text cursor will blink.' type: #Boolean>}.
       
I think that corresponds with his message today:


 Having it as a message pattern means:
- one can search for references to the method tag by searching for senders
of the message tag's selector

But the ultimate destination of all method annotations is a #perform:?

Not necessarily, but often this can be a powerful pattern.  If a method tag means something, can be interpreted somehow, then effecting this interpretation via a perform is delightfully direct and minimal.  But sometimes the meaning is beyond the system (e.g. as I wrote to myself today <flag: 'rewrite this crap.'> ;) ) and so there is no interpretation that can be implemented in Smalltalk code.

I take that from this:


- one can provide implementation(s) of the selector and hence execute the
method tag using perform

So the ultimate destination of all pragmas/method annotations/method tags is that somewhere a #perform: lurks waiting
for it? Sometimes that's the Compiler class and sometimes it's another class with a #perform:.

Certainly that's possible for a significant subset of  potential uses.


I'd appreciate it if somebody could say if this is an accurate picture.
A "yes" will do it.

yes, with caveats :)

best
Eliot
 

Chris

Stitch: I'm having a good day 



Reply | Threaded
Open this post in threaded view
|

Re: Pragma support in Squeak/Pharo/Cuis

Chris Muller-3
Thanks for this great discussion y'all; it's great to learn from your
experience about good uses for pragmas.

On Fri, Jan 28, 2011 at 5:16 PM, Eliot Miranda <[hidden email]> wrote:

>
>
> On Fri, Jan 28, 2011 at 1:39 PM, Chris Cunnington
> <[hidden email]> wrote:
>>
>> I've got some notes from 2 May 2010 about pragmas. Eliot produced this
>> example at the time:
>>
>>        x := Editor class compiledMethodAt: #blinkingCursor.
>>
>>        x pragmas
>> {<preference: 'Blinking Text Cursor' category: 'Morphic' description:
>> 'When true, the text cursor will blink.' type: #Boolean>}.
>>
>> I think that corresponds with his message today:
>>
>>>  Having it as a message pattern means:
>>> - one can search for references to the method tag by searching for
>>> senders
>>> of the message tag's selector
>>
>> But the ultimate destination of all method annotations is a #perform:?
>
> Not necessarily, but often this can be a powerful pattern.  If a method tag
> means something, can be interpreted somehow, then effecting this
> interpretation via a perform is delightfully direct and minimal.  But
> sometimes the meaning is beyond the system (e.g. as I wrote to myself today
> <flag: 'rewrite this crap.'> ;) ) and so there is no interpretation that can
> be implemented in Smalltalk code.
>>
>> I take that from this:
>>
>>> - one can provide implementation(s) of the selector and hence execute the
>>> method tag using perform
>>
>> So the ultimate destination of all pragmas/method annotations/method tags
>> is that somewhere a #perform: lurks waiting
>> for it? Sometimes that's the Compiler class and sometimes it's another
>> class with a #perform:.
>
> Certainly that's possible for a significant subset of  potential uses.
>>
>> I'd appreciate it if somebody could say if this is an accurate picture.
>> A "yes" will do it.
>
> yes, with caveats :)
> best
> Eliot
>
>>
>> Chris
>
> Stitch: I'm having a good day
>
>
>
>