On Sat, Feb 7, 2015 at 10:21 AM, Thierry Goubier <[email protected]> wrote:
> > > 2015-02-07 18:48 GMT+01:00 Eliot Miranda <[email protected]>: > >> Hi Hernan, >> >> On Sat, Feb 7, 2015 at 7:41 AM, Hernán Morales Durand < >> [email protected]> wrote: >> >>> >>> 2015-02-07 5:59 GMT-03:00 kilon alios <[email protected]>: >>> >>>> 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 :)) > 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. > (And C #pragmas are clearly more powerfull than Smalltalk's, since they > are not required to be at the start of the function only) > Sure. Pragmas associate with methods, not statements. > 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" ... > 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. Thierry > -- best, Eliot
