2015-02-07 18:48 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:

Hi Hernan,

On Sat, Feb 7, 2015 at 7:41 AM, Hern�n Morales Durand <hernan.morales@gmail.com> wrote:

2015-02-07 5:59 GMT-03:00 kilon alios <kilon.alios@gmail.com>:
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