||

On Fri, Feb 6, 2015 at 1:58 AM, Thierry Goubier <[hidden email]> wrote:

Hi Eliot,

maybe I'll frame the core question a bit differently, thanks to your explanations.

I see pragmas used mainly for two things:

1- expressing a link to some metadata used by low level tools: compiler, C lang generator, etc... primitives for me are part of that. Kind of neat to see that unified.

There's a third use that is, I think, the most powerful.  Maybe you see this as the same as 1, but I don't.  The method is a component to be included in some larger structure, e.g. it is an action method on a menu, or it is an implementation of a pane in an inspector.  The pragma is the message to be sent to the object that manipulates that larger structure to add the method to it.  This is how menu pragmas work in VW.  There is an object called a MenuBuilder.  To add a method to a menu (and which menu is described by the pragma) the menu builder sets the method as its current method and then performs the pragma.  The parameters in the pragma allow the MenuBuilder to add the method in the right way to the menu.  But the execution of the pragma is what actually adds the mehtod to the menu.  So its a combination of specification and execution.

I have no problem with your criticism of pragmas used for categorisation.  Method categories are already there and sometimes much more appropriate than pragmas.  For example, in the SPur bootstrap the methods to be added or modified in Spur are included in categories of SpurBootstrapPrototypes and its subclasses.  If there were pragmas in these methods then the pragmas would be copied into Spur, which is not at all what I want.  Instead I copy across the methods in the relevant categories.

But this "not a complete solution" feels to me an unfair criticism.  Pragmas are what they are and they can do a lot.  But no part of the system does everything.  A system is composed of components.

2015-02-06 18:29 GMT+01:00 Eliot Miranda <[hidden email]>:

On Fri, Feb 6, 2015 at 1:58 AM, Thierry Goubier <[hidden email]> wrote:

Hi Eliot,

maybe I'll frame the core question a bit differently, thanks to your explanations.

I see pragmas used mainly for two things:

1- expressing a link to some metadata used by low level tools: compiler, C lang generator, etc... primitives for me are part of that. Kind of neat to see that unified.

There's a third use that is, I think, the most powerful.  Maybe you see this as the same as 1, but I don't.  The method is a component to be included in some larger structure, e.g. it is an action method on a menu, or it is an implementation of a pane in an inspector.  The pragma is the message to be sent to the object that manipulates that larger structure to add the method to it.  This is how menu pragmas work in VW.  There is an object called a MenuBuilder.  To add a method to a menu (and which menu is described by the pragma) the menu builder sets the method as its current method and then performs the pragma.  The parameters in the pragma allow the MenuBuilder to add the method in the right way to the menu.  But the execution of the pragma is what actually adds the mehtod to the menu.  So its a combination of specification and execution.

You mean as a sort of lightweight command object? Pharo uses that for its world menu, Nautilus for its menus, and probably in a few other places. I also like to define command objects for that purpose, because it gives you more flexibility and power while keeping all concerns together: complex commands depending on the context of their creator, having both a menu entry and a shortcut, controlling whether they are enabled or not... I also like command objects because they usually force a bit of a dedicated category for them, and may avoid a spread of pragmas tagged methods left and right in the package.

I have no problem with your criticism of pragmas used for categorisation.  Method categories are already there and sometimes much more appropriate than pragmas.  For example, in the SPur bootstrap the methods to be added or modified in Spur are included in categories of SpurBootstrapPrototypes and its subclasses.  If there were pragmas in these methods then the pragmas would be copied into Spur, which is not at all what I want.  Instead I copy across the methods in the relevant categories.

But this "not a complete solution" feels to me an unfair criticism.  Pragmas are what they are and they can do a lot.  But no part of the system does everything.  A system is composed of components.

I agree with that, and the fact that well, maybe, someone will come along with something better :)

Thierry

Or are you talking about the lack of class pragmas?  This is a point.  But classes already have an executable hook they can use for system modification, their class-side initialize and obsolete methods.  That's been used for a long time to address system modification needs on installing and removing classes.  So form that perspective there's less of a need to class pragmas.  Instead we're focussing on more specialised class definition facilities such as slots, which are intrinsic to classes, i.e. define the class itself, rather than pragmas, which are extrinsic to methods in that they define how methods interact in the system outside themselves.

Really interesting discussion. I like pragmas but this is interesting to see them challenged.

Yes, but there end up being lots of naming conventions and they are non-obvious.  Whereas pragmas, because they are in-your-face in the methods in question, don't need conventions. They just need documenting ;-).

Thierry I'm skeptical that multiple protocol will save the problem because you will rely on coding conventions.

And pragma is a clever tagging.

Stef

Personally I don't like Pragmas, they have not convinced me so far that they fit the style of Smalltalk syntax. I have to confess though I never liked descriptive elements and languages . 

About python decorators I disagree that are similar to pragmas. Pragmas are focused on being descriptive , python decorators are descriptive as by product. The main focus of python decorators is to shorten code by introducing syntactic sugar. 

I agree though this is a very interesting discussion and I dont understand most of the things stated here so I leave an open door and mind for pragmas. Maybe one day I will "get it". 

On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier <[hidden email]> wrote:

2015-02-06 22:00 GMT+01:00 stepharo <[hidden email]>:

Really interesting discussion. I like pragmas but this is interesting to see them challenged.

Thanks. It's a pleasure to discuss that way :)

 

Yes, but there end up being lots of naming conventions and they are non-obvious.  Whereas pragmas, because they are in-your-face in the methods in question, don't need conventions. They just need documenting ;-).

Thierry I'm skeptical that multiple protocol will save the problem because you will rely on coding conventions.

Pragma as well: just explain the conventions behind the gtInspector pragmas, for example.

But give me multiple protocols and I'll show you the same conventions rewritten in less lines (and a slightly more efficient code).

 

And pragma is a clever tagging.

Then maybe we should remove protocols and replace them with pragmas :)

Thierry

 

Stef

2015-02-07 5:59 GMT-03:00 kilon alios <[hidden email]>:

Personally I don't like Pragmas, they have not convinced me so far that they fit the style of Smalltalk syntax. I have to confess though I never liked descriptive elements and languages . 

Me neither. Actually the pragma idea is not wrong per se, it is the tag syntax to write them which bothers me. Because the world can be described with tags if you start that path.

There are other ways to add metadata to methods. Without tagging.

And they don't need to be in the method pane itself.

It is like having to specify protocol because there is no list pane to create them.

Hernán

 

About python decorators I disagree that are similar to pragmas. Pragmas are focused on being descriptive , python decorators are descriptive as by product. The main focus of python decorators is to shorten code by introducing syntactic sugar. 

I agree though this is a very interesting discussion and I dont understand most of the things stated here so I leave an open door and mind for pragmas. Maybe one day I will "get it". 

 

On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier <[hidden email]> wrote:

2015-02-06 22:00 GMT+01:00 stepharo <[hidden email]>:

Really interesting discussion. I like pragmas but this is interesting to see them challenged.

Thanks. It's a pleasure to discuss that way :)

 

Yes, but there end up being lots of naming conventions and they are non-obvious.  Whereas pragmas, because they are in-your-face in the methods in question, don't need conventions. They just need documenting ;-).

Thierry I'm skeptical that multiple protocol will save the problem because you will rely on coding conventions.

Pragma as well: just explain the conventions behind the gtInspector pragmas, for example.

But give me multiple protocols and I'll show you the same conventions rewritten in less lines (and a slightly more efficient code).

 

And pragma is a clever tagging.

Then maybe we should remove protocols and replace them with pragmas :)

Thierry

 

Stef

Hi Hernan,

On Sat, Feb 7, 2015 at 7:41 AM, Hernán Morales Durand <[hidden email]> wrote:

2015-02-07 5:59 GMT-03:00 kilon alios <[hidden email]>:

Personally I don't like Pragmas, they have not convinced me so far that they fit the style of Smalltalk syntax. I have to confess though I never liked descriptive elements and languages . 

Me neither. Actually the pragma idea is not wrong per se, it is the tag syntax to write them which bothers me. Because the world can be described with tags if you start that path.

How exactly is the syntax wrong?

The <literalMessagePattern> syntax predates pragmas.  It was used first for numeric primitives in Smalltalk-76 or Smalltalk-80.  Squeak extended it with primitive:module:.  I and others extended it to include arbitrary literal message patterns.  The syntax of a literal message pattern is the syntax of a send with no receiver and only literal arguments.  The use of this syntax means

a) no new syntax

b) each pragma is potentially executable

c) methods using specific pragmas can be found using "find senders"

d) the execution side of a pragma can be found using "find implementors"

So what's wrong with that?  How is it wrong to use a common Smalltalk object, a Message, that is well-supported in the system, for method metadata?

 

There are other ways to add metadata to methods. Without tagging.

Haven't we discussed that?  Putting metadata off to the side introduces a bookkeeping problem.  It is a bad idea.

 

And they don't need to be in the method pane itself.

For some kinds of metadata, for metadata with semantics, not just a documentary function, it is important for the metadata to be obvious.  No one has argued for hiding the primitive specification off-to-the-side.  "Need" is a poor criticism here because using turing equivalence lots of things don't "need" to be the way they are.  Instead why not ask what are the pros and cons?

 

It is like having to specify protocol because there is no list pane to create them.

I disagree.  When the pragma is specifying type information, specifying that the method is an action on a specific menu, is a pane in an inspector, and many other uses, it is essential that that information be represented, and putting it in a one-off bookkeeping system is a bad idea.  We're not talking about simple documentary metadata like author, category etc.  We're using pragmas for semantics, semantics of the method that are outside of its execution semantics, semantics about how the method fits in the broader system.  And putting that in non-obvious places is a bad idea.  

2015-02-07 18:48 GMT+01:00 Eliot Miranda <[hidden email]>:

Hi Hernan,

On Sat, Feb 7, 2015 at 7:41 AM, Hernán Morales Durand <[hidden email]> wrote:

2015-02-07 5:59 GMT-03:00 kilon alios <[hidden email]>:

Personally I don't like Pragmas, they have not convinced me so far that they fit the style of Smalltalk syntax. I have to confess though I never liked descriptive elements and languages . 

Me neither. Actually the pragma idea is not wrong per se, it is the tag syntax to write them which bothers me. Because the world can be described with tags if you start that path.

How exactly is the syntax wrong?

The <literalMessagePattern> syntax predates pragmas.  It was used first for numeric primitives in Smalltalk-76 or Smalltalk-80.  Squeak extended it with primitive:module:.  I and others extended it to include arbitrary literal message patterns.  The syntax of a literal message pattern is the syntax of a send with no receiver and only literal arguments.  The use of this syntax means

a) no new syntax

b) each pragma is potentially executable

c) methods using specific pragmas can be found using "find senders"

d) the execution side of a pragma can be found using "find implementors"

So what's wrong with that?  How is it wrong to use a common Smalltalk object, a Message, that is well-supported in the system, for method metadata?

The point was: descriptive and the world could be described  by tags :) Message syntax for pragmas is just a consequence of the original primitive syntax, nothing else (I.e. natural syntax extension). Given how it is used and that the "potentially executable" is just that, potential, array literals would work just as well (and I'm nearly sure that a todays design for pragmas would give us something like STON content :))

There are other ways to add metadata to methods. Without tagging.

Haven't we discussed that?  Putting metadata off to the side introduces a bookkeeping problem.  It is a bad idea.

And pragmas only partially address that.

Imagine that Sista works, that it has dozens of tuning points for a method (int, no recurse, vect, is a reduce, openCL, thread-safe, hot point, this loop should be enrolled) do you imagine writing all that into the method to guide Sista with pragmas? You'll end up in exactly the same situation as OpenMP 4, where it is possible to write programs with more #pragma lines than C/C++ code.

(And C #pragmas are clearly more powerfull than Smalltalk's, since they are not required to be at the start of the function only)

And they don't need to be in the method pane itself.

For some kinds of metadata, for metadata with semantics, not just a documentary function, it is important for the metadata to be obvious.  No one has argued for hiding the primitive specification off-to-the-side.  "Need" is a poor criticism here because using turing equivalence lots of things don't "need" to be the way they are.  Instead why not ask what are the pros and cons?

 

It is like having to specify protocol because there is no list pane to create them.

I disagree.  When the pragma is specifying type information, specifying that the method is an action on a specific menu, is a pane in an inspector, and many other uses, it is essential that that information be represented, and putting it in a one-off bookkeeping system is a bad idea.  We're not talking about simple documentary metadata like author, category etc.  We're using pragmas for semantics, semantics of the method that are outside of its execution semantics, semantics about how the method fits in the broader system.  And putting that in non-obvious places is a bad idea.  

Good, you're giving my favorite examples for what pragmas are redundant :)

The method with the menu pragma is named "worldMenuCommand" ...

The method with the gtInspector pragma is named "gtInspectorPresentation..."

Additionally, as I told you before: the pragma semantic isn't in the method... It's somewhere else in the system and senders of that pragma doesn't get it.

Just have a look at OmniBrowser and tell me that you don't understand where the menu commands are :)

Thierry

Array literals are not executable.  They are literals.  They need an interpreter to add semantics.  This is one of the reasons why Spec is poor.  Pragmas are Message instances.  They respond to sendTo:/sentTo:.  STON is not executable, it needs an interpreter.

There are other ways to add metadata to methods. Without tagging.

Haven't we discussed that?  Putting metadata off to the side introduces a bookkeeping problem.  It is a bad idea.

And pragmas only partially address that.

Partially?  It completely solves the issue of keeping metadata associated with a method.

Imagine that Sista works, that it has dozens of tuning points for a method (int, no recurse, vect, is a reduce, openCL, thread-safe, hot point, this loop should be enrolled) do you imagine writing all that into the method to guide Sista with pragmas? You'll end up in exactly the same situation as OpenMP 4, where it is possible to write programs with more #pragma lines than C/C++ code.

One doesn't need a line per option.  One can use... literal arrays
    someImportantMethod        <sistaTuningHints: #(threadSafe unroll)>
but for Sista we imagine very few tuning options, perhaps only one, which is to say to the optimizer optimize this method even if it doesn't show up as a hot spot.  Sista is /not/ going to look like gcc.

 

The method with the menu pragma is named "worldMenuCommand" ...

I don't see examples of this in the pharo 4 image I have to hand.  What's the full selector?

 

The method with the gtInspector pragma is named "gtInspectorPresentation..."

This one is ok.  The pragma both says the method is a pane in a glamour inspector, and says what the order is relative to others.  One thing that's broken is that the finder doesn't find any senders.  Another thing is that the pragma doesn't do anything.  If the Glamour inspector added panes to itself by using sentTo: to evaluate the pragma then when you did "implementors" you'd find the builder.

So those examples are not taking full advantage.  In VW they're more interesting, e.g. 

searchForStringInSource

"Spawn a Browser on all methods which contain a specified string."

<menuItem: #(#MethodsWithPhraseDot #menus 'Methods with &Phrase...')

nameKey: nil

menu: #(#listMenu #browse) 

position: 21.03 >

...

which says which sub menu it is in (listMenu browse), where it is relative to other entries (21.03), what its hot key is (P). And MenuAutomaticGeneraotr implements the pragma (which shows up though the "implementors" menu on the menu pragma method):
menuItem: label nameKey: key menu: menuIDs position: position "If the method is to be inserted into our menu, create a MenuItem, otherwise answer nil." | realLabel | menuIDs first = menuName ifFalse: [^nil]. realLabel := self decodeLabel: label. ^Array with: ((MenuItem labeled: realLabel) nameKey: key) with: (menuIDs copyFrom: 2 to: menuIDs size) with: position

Additionally, as I told you before: the pragma semantic isn't in the method... It's somewhere else in the system and senders of that pragma doesn't get it.

I know that very well.  If things are done right, that the finder will find pragmas via "senders", and if the designer has chosen to implement the pragma in some processing object, then the link is made.  But I disagree that the semantic is entirely elsewhere in the system.  The /implementation/ is elsewhere in the system.  The semantic is in the pragma, in exactly the same way as a message specifies an operation to be performed and a method specifies an implementation, because... pragmas are messages.

Just have a look at OmniBrowser and tell me that you don't understand where the menu commands are :)

I don't want to criticise OmniBrowser, but if pragmas are used in the pattern above those relationships become clear.