[squeak-dev] Pragmas (Re: The Inbox: Morphic-phite.429.mcz)

Igor Stasenko siguctua at gmail.com
Mon Apr 26 20:14:41 UTC 2010


On 26 April 2010 22:05, Andreas Raab <andreas.raab at gmx.de> wrote:
> On 4/26/2010 11:48 AM, Eliot Miranda wrote:
>>
>> OK, so Pragma is bad; its historical from "primitive pragma".  But
>> Annotation doesn't capture the potentially executable flavour of
>> pragmas.  How about MethodMetaMessage?  (mmm, yum :) )  We could talk
>> about meta-messages for short. "Add a meta-message that does ..." etc...
>
> But "primitive pragma" is every bit as wrong. A pragma is something that
> gives the compiler information about the code without being code itself.
> Primitives are't pragmas, primitives are *code* (if you don't believe me,
> just remove all of them and see how that goes).
>
> By definition, a "pragma" is an interface between the code and the compiler,
> something where the code conveys meta-information to the compiler. For
> example, this is a pragma (assuming the compiler understands it):
>
> foo
>        <inline: true>
>
> bar
>        <tailcut: true>
>
> The first one might instruct the compiler to generate the code for this
> method inline, the second one to eliminate tail recursion.
>
> None of these, however, are pragmas:
>
> foo
>        "Not a pragma since it's not for the compiler"
>        <preference: 'Foo Preference'
>          ...
>        >
>
> apiGetWindowFocus
>        "Not a pragma since it's code"
>        <apicall: ulong 'GetWindowFocus' (void)>
>
> etc. I should also add that before the introduction of the so-called
> "pragmas" there was only *code* used in the <> syntax (primitives and FFI
> calls) and the change to allow non-code entities is something that, although
> useful, still worries me because of the conceptual issues associated with
> mixing code and non-code entities. We wouldn't even have that discussion if
> <> just meant "code".
>

Pragmas are not code, even in old and limited forms, they simply
contain a meta-information for compiler.
If pragmas would be the code, then i expect them to look like code i.e.:
<[  | x y |  x := 5. y:= 6. x+y ] >

I treat a pragma as a message, sent to compiler/parser framework i.e.
whenever compiler sees:

< foo: a with: z bar: zork>

its can be simply interpreted as a message sent to compiler(or parser):
pragmaConsumer foo: a with: z bar: zork

where pragmaConsumer is an object which can do anything it wants for
taking this information into account, when processing the method's
source code.

Btw, it would be interesting to alter the compiler framework to
support that cleanly.
We can use a special class, PragmaProcessor , with all the messages like

PragmaProcessor >> primitive: aPrimitiveName module: aModuleName

and parser , in its #addPragma:  could simply do:


addPragma: aPragma
  properties := self properties copyWith: aPragma
"pragmaProcessor is a previously initialized PragmaProcessor instance"
(pragmaProcessor respondsTo: aPragma keyword ) ifTrue: [
  pragmaProcessor perform: aPragma keyword withArguments: aPragma arguments. ]

pragma processor then can call back the parser/compiler in case of
need (like adding a primitive literal,
setting a method's prim index etc), or do whatever extra it needs.

so, then we can keep a pragma processing code aside of parser/compiler
and extend it easily to support various stuff we may need.

> Cheers,
>  - Andreas
>

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list