On Fri, Feb 6, 2015 at 1:58 AM, Thierry Goubier <thierry.goub...@gmail.com> 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. 2- categorizing things in a decoupled, package-extension compatible way. > > I still think there is something in the design that bother me. 1- and 2- > are convention-based, so as is most of Smalltalk anyway, so diregarding > another approach to 2- as convention-based is a bit dishonest: pragmas get > more authority because they look like they have been integrated in the > language definition compared to competing solutions. > Yes, it's right to say they have been integrated (but no documented). No, this is just because I start to wonder if methods shouldn't have a bit > more in that "define, add and manipulate" metadata idea, i.e. make it more > explicit and start to have tools which represent methods as more like > objects and not only text items (methods having metadata, additional slots > or instance variables, counters, statistics, ast, traces, break points, > etc...). And, in a way, a need to have two levels of execution: one which > happens at compile time (i.e. when one accept a method), one which happens > at runtime. > I think whether methods are objects or text is in the eye of the beholder. >From my perspective methods /are/ objects. The textual display and compilation of them is only the conventional programmer view of them. Bu from a system perspective methods are objects. Look for example at all the debugger machinery. That is largely concerned with bytecodes in method objects. For that, I think pragmas are a start, but they are not the complete > answer. And I think we should solve the package-extension compatible thing > in 2- to not have 2- (which is just for me a plain categorisation issue) > polluting the design by introducing additional/unrelated requirements. > 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-05 22:47 GMT+01:00 Eliot Miranda <eliot.mira...@gmail.com>: > >> Hi Thierry, >> >> A block is far more difficult to deal with than a pragma. A pragma has a >> simple key, its selector, and simple access to its arameters, the >> arguments. A block is opaque. Essentially it can only be executable. >> Pragmas are both executable and function as annotations. >> > > Pragmas are executable, but in a context which is not visible at the place > they are written. > > >> >> >> >>> I strongly agree with your keep it in sync argument, still. Pragmas are >>> better than nothing. >>> >>>> >>>> >>>> There is no such need with pragmas; they are always in sync with the >>>> methods they describe because they are embedded in their methods. Instead >>>> we can use triggering to do useful things, adding a pane to open inspectors >>>> as soon as we define the method that describes the pane, adding or removing >>>> a menu entry, etc. >>>> >>> >>> Just a naming convention does just that perfectly fine, and with less >>> lines (except for extensions by external packages) and faster code in many >>> cases. >>> >> >> 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 ;-). >> > > They are still conventions which needs documentation. Pragmas are, in > allmost all uses, indirections (i.e. a tag meaning something to a far away > object), and the meaning associated to a pragma is, in every case, a > roll-your-own solution. And they are clearly "in your face" :) > > >> >> >> That's not necessarily true. Some pragmas do cause processing at compile >> time. For example, an FFI signature pragma can be checked at >> compile-time. But it's in keeping with smalltalk that type checking is not >> performed at compile time in most cases, isn't it? Why should one require >> that pragmas be semantically checked at compile time when normal SMalltalk >> code isn't? At least one knows that the message instance the pragma is >> compiled to is a valid object and *can* be performed. So pone does know at >> least that the pragma is executable. Obviously whether that ability to be >> executed only becomes potent with the right receiver. So any compiled >> pragma as the potential to be usefully evaluated. >> > > Ok, but its all fuzzy. > > It may be executed, but it may be not. > > It may send an error if incorrect, but it may fail silently. > > It may be executed at compile time, it may be executed sometime later > triggered by the compilation, or it may be executed at runtime, as if it > was normal code. And of course it may not be executed at all ... > > You see what I mean? > > >> >> And often it doesn't matter if the pragma reference a completely non >>> existent method or api, since it is probably never executed by anybody (and >>> if it is, it won't probably reify the error message properly as a >>> compilation error as it should, because it may be triggered miles away from >>> the system browser). >>> >> >> >> There is lots about Smalltalk that is non-obvious, about programming in >> general that is non-obvious. I don't see that as a specific criticism of >> pragmas. Once one knows the idiom it is easy to use; its wide-spread use >> is evidence of that. And hopefully this conversation will help make it >> more obvious :-). That it is limited is also not perhaps a useful >> criticism. The issue is whether it is adequate. I think it is. A literal >> message goes a long way. I'e not heard of complaints about limitations so >> far. Do you have specific examples where pragmas are inadequate? The >> tools /do/ support them. One can do senders and implementors in the >> browser and see the methods that include them, and the implementors of >> pragmas. browseAllSelect: will narrow down the search. There is an API >> for programmatic use (pragmasDo: et al). >> > > See [*][**] for the tools support. For me, pragmas, even in their > definition, have serious semantic issues. If they were strictly, as you > describe them, a metadata API access executed at compile time, then they > would be a lot stronger. > > Make them sent at compile-time on the method object, and that would > probably solve all the true arguments I have against them :) > > for example: <worldMenu> against <tagAndAnnounce: #worldMenu>; <tag: > #gtInspectorExtension> instead of <gtInspectorExtension>, etc... > > (<tagAndAnnounce:> would gain a bit of performance, as well). > > Thierry > > [*] Searching a bit for menu pragmas in a Pharo image seems to return a > bit of a mess. There is so many of them, all differents, and interestingly, > this does not return the code triggered (or using) them, which makes > discovery of what the pragma is used for (and its parameters) an > 'interesting' problem. > > I suggest a task then: an illustrated sequence of how to search for the > code triggering world menu addition of a new command, for someone which is > new to Pharo ;) > > [**] even when used for categorisation, the API is prone to bugs, such as > having a method without pragma overriding a superclass method with pragma > because they have the same name. > > > -- best, Eliot
