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 |
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 |
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 |
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). > 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. |
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 |
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 |
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 |
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 |
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 > |
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 > |
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. |
In reply to this post by Casey Ransberger-2
On Fri, Jan 28, 2011 at 10:38 AM, Casey Ransberger <[hidden email]> wrote: +1 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
|
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 |
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. |
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 |
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: 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: Certainly that's possible for a significant subset of potential uses.
yes, with caveats :) best Eliot
Stitch: I'm having a good day |
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 > > > > |
Free forum by Nabble | Edit this page |