Pragma syntax

Hi,
I'll probably be shot down in flames for this suggestion, but...

Why isn't the syntax for pragmas something like this...

<pragma: A value: 10>
<pragma: a:b: value: {1. 2}>
or maybe, <pragma: a: 1 b: 2>

At present, if I compile a method containing
    <primitive: 'a' module: 'b'>
I get a primitive.

But if I've made a typo...
    <primitive: 'a' moduel: 'b'>
I get a pragma. Which is almost certainly not what I wanted.
Of course, the compiler could check that if the first part is primitive: then
the second part is module: , but what about...
    <primitiv: 1>  [sic]
Once again I get a pragma.

Now, <pragma: , can be used for REAL pragmas (ones that do not generate code).
And I can happily add code-generating angle bracket constructs, which have any
syntax I like e.g.
    <sql: select * from mytable>
    <javascript: ...>

Cheers,
Andy

> Why isn't the syntax for pragmas something like this...
>
> <pragma: A value: 10>
> <pragma: a:b: value: {1. 2}>
> or maybe, <pragma: a: 1 b: 2>

I don't see how this could help to avid typing errors? Moreover it
makes pragmas much more verbose, incompatible with other
implementations, and harder to read.

> But if I've made a typo...
>     <primitive: 'a' moduel: 'b'>
> I get a pragma. Which is almost certainly not what I wanted.
> Of course, the compiler could check that if the first part is primitive: then
> the second part is module: , but what about...
>     <primitiv: 1>  [sic]
> Once again I get a pragma.

I wouldn't do a distinction between pragmas and primitives. In my
opinion primitive pragmas (in your language code-generating angle
bracket constructs) are the same as any other pragma, the only
difference is that they are interpreted by the compiler. This can be
done in a very clean way as I proposed in the FFI thread.

Now, assuming that primitive-pragmas are the same as any other pragma,
how can we avoid typing mistakes in pragma declarations? Actually this
problem is not new, it also happened to me several times. Let me
propose two different solutions:

- In VisualWorks you have to declare pragmas (using pragmas) if you
want to use them. This would solve the problem, though I don't
particularly like it because Smalltalk is not about declaring things.
It also creates new dependencies between code that is not easy to cope
with. So I don't think this would be a good solution.

- Introduce a similar correction mechanism for pragmas as we do for
message selectors that are unknown to the system. This would pop-up a
message in case the pragma is not already known to the system and
allow the user to proceed or correct it. I think this would be a nice
solution, though it has the drawback that once you misspelled your
pragma you don't get a warning anymore.

What do you think?

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Hi Lukas,
----- Original Message -----
From: "Lukas Renggli" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Friday, August 18, 2006 12:37 PM
Subject: Re: Pragma syntax


> > Why isn't the syntax for pragmas something like this...
> >
> > <pragma: A value: 10>
> > <pragma: a:b: value: {1. 2}>
> > or maybe, <pragma: a: 1 b: 2>
>
> I don't see how this could help to avid typing errors? Moreover it
> makes pragmas much more verbose, incompatible with other
> implementations, and harder to read.

you make 4 points, I'll take them in turn

1. Doesn't help avoid typing errors
    I had in mind that only anything that didn't begin <primitive: or <pragma:
would be rejected by the compiler, unless there was a compiler extension (e.g.
FFI that added others - <cdecl: etc).

2. More verbose.
    Yes, but is that necessarily a bad thing? I mean <primitive: 1> could be
written <1>, but I don't think it's better.

3. Incompatible with other implementations.
     Compatibility is a good thing to strive for. Maybe it is part of the ANSI
standard? (I don't know, I'd have to check)

4. Harder to read.
    For standard pragmas, yes, I would agree with that. But, is readability for
<> constructs that do not fit into the standard pragma syntax improved (or, in
the case of FFI, maintained). Here I am thinking of my sql example. <sql: select
* from table>. It would be less verbose, and easier to read to just write
<select * from table>, but it now looks like a pragma with invalid syntax,
rather than a special <sql: type thing. My idea was to give equal status to
primitives, pragmas, FFI, and anything else that comes along later. The current
pragma syntax tries to force everything to be a pragma, which seems to me to be
a bad thing, and I was trying to come up with a way of avoiding that.

>
> > But if I've made a typo...
> >     <primitive: 'a' moduel: 'b'>
> > I get a pragma. Which is almost certainly not what I wanted.
> > Of course, the compiler could check that if the first part is primitive:
then
> > the second part is module: , but what about...
> >     <primitiv: 1>  [sic]
> > Once again I get a pragma.
>
> I wouldn't do a distinction between pragmas and primitives. In my
> opinion primitive pragmas (in your language code-generating angle
> bracket constructs) are the same as any other pragma, the only
> difference is that they are interpreted by the compiler. This can be
> done in a very clean way as I proposed in the FFI thread.

On the other hand, I would make a distinction between primitives and pragmas.
Primitives are not pragmas. So they aren't like any other pragma, simply because
they aren't pragmas.
Note, in my syntax  you could have a pragma named primitive: - <pragma:
primitive: $b> , but this wouldn't have any connection to real primitive calls
(which are code).

>
> Now, assuming that primitive-pragmas are the same as any other pragma,

ok. For the sake of the discussion, I'll make that assumption

> how can we avoid typing mistakes in pragma declarations? Actually this
> problem is not new, it also happened to me several times. Let me
> propose two different solutions:
>
> - In VisualWorks you have to declare pragmas (using pragmas) if you
> want to use them. This would solve the problem, though I don't
> particularly like it because Smalltalk is not about declaring things.
> It also creates new dependencies between code that is not easy to cope
> with. So I don't think this would be a good solution.

agreed.

>
> - Introduce a similar correction mechanism for pragmas as we do for
> message selectors that are unknown to the system. This would pop-up a
> message in case the pragma is not already known to the system and
> allow the user to proceed or correct it. I think this would be a nice
> solution, though it has the drawback that once you misspelled your
> pragma you don't get a warning anymore.

That seems like a better solution.

Cheers,
Andy

> 1. Doesn't help avoid typing errors
>     I had in mind that only anything that didn't begin <primitive: or <pragma:
> would be rejected by the compiler, unless there was a compiler extension (e.g.
> FFI that added others - <cdecl: etc).

My point was that there are not only primitives that can be
misspelled, but any other pragma as well and that kind of misspelling
is a possible cause for bugs.

> 2. More verbose.
>     Yes, but is that necessarily a bad thing? I mean <primitive: 1> could be
> written <1>, but I don't think it's better.

"A pragma is a message-send composed of a selector and a literal array
of arguments."

<1> and the FFI syntax don't comply to this definition.

> 3. Incompatible with other implementations.
>      Compatibility is a good thing to strive for. Maybe it is part of the ANSI
> standard? (I don't know, I'd have to check)

Pragmas are not part of ANSI, neither are primitives or FFI. It is
just that the most important commercial competitor of Squeak
(VisualWorks) is using this syntax. There are other Smalltalk using it
as well, so it is a quasi standard, I would say.

> the case of FFI, maintained). Here I am thinking of my sql example. <sql: select
> * from table>.

Put the SQL inside a string <sql: 'select * from table'>. If we allow
anybody to build its own pragma syntax, everybody has to extend/patch
the compilers, the parsers, the syntax highlighters, the code
completors, the decompilers, etc. For me it doesn't makes sense to
allow this kind of customization, it complicates things. A pragma is a
message-send composed of a selector and a literal array of arguments:
this is simple, powerful and nicely integrates with the existing
Smalltalk syntax and tools.

> rather than a special <sql: type thing. My idea was to give equal status to
> primitives, pragmas, FFI, and anything else that comes along later. The current
> pragma syntax tries to force everything to be a pragma, which seems to me to be
> a bad thing, and I was trying to come up with a way of avoiding that.

Yes, what makes things simpler, because you only need one parser, one
compiler, one syntax highlighter, one code competition, one decompiler
and all those tool work well together with the system without having
to extend and patch them.

Btw, did you know that you get a list of all primitive functions if
you look for the senders of #primitive:module: in a 3.9 image? That
wouldn't work so nicely and for free if a primitive wouldn't be
modelled using a pragma.

> On the other hand, I would make a distinction between primitives and pragmas.
> Primitives are not pragmas. So they aren't like any other pragma, simply because
> they aren't pragmas.

I do model primitives as pragmas. I do love it. It completely makes
sense. It is done like this in 3.9 (except for FFI). It makes the
compiler much simpler. It nicely integrates with the tools.

> > - Introduce a similar correction mechanism for pragmas as we do for
> > message selectors that are unknown to the system. This would pop-up a
> > message in case the pragma is not already known to the system and
> > allow the user to proceed or correct it. I think this would be a nice
> > solution, though it has the drawback that once you misspelled your
> > pragma you don't get a warning anymore.
>
> That seems like a better solution.

I can come up with a fix for that.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

----- Original Message -----
From: "Lukas Renggli" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Friday, August 18, 2006 2:35 PM
Subject: Re: Re: Pragma syntax


> > 1. Doesn't help avoid typing errors
> >     I had in mind that only anything that didn't begin <primitive: or
<pragma:
> > would be rejected by the compiler, unless there was a compiler extension
(e.g.

If that is the definition, then aren't  <+ 2>  , << 'a'>  and  <> 4> also
pragmas?
It would be nicely consistent if they were.



>
> > 3. Incompatible with other implementations.
> >      Compatibility is a good thing to strive for. Maybe it is part of the
ANSI
> > standard? (I don't know, I'd have to check)
>
> Pragmas are not part of ANSI, neither are primitives or FFI. It is
> just that the most important commercial competitor of Squeak
> (VisualWorks) is using this syntax. There are other Smalltalk using it
> as well, so it is a quasi standard, I would say.
>
> > the case of FFI, maintained). Here I am thinking of my sql example. <sql:
select current
> > pragma syntax tries to force everything to be a pragma, which seems to me to
be
Yes. Free is good.

>
> > On the other hand, I would make a distinction between primitives and
pragmas.
> > Primitives are not pragmas. So they aren't like any other pragma, simply
because
> > they aren't pragmas.
>
> I do model primitives as pragmas. I do love it. It completely makes
> sense. It is done like this in 3.9 (except for FFI). It makes the
> compiler much simpler. It nicely integrates with the tools.

ok. You've convinced me,  I suspected that you would :)
Cheers,
Andy

Me too! Thanks lukas. Thanks andy for your nice exchange. I will this  
kind of discussion
where at the end I have learned or realized that I knew something but  
he was deep into
my mind and not clear enough.

While reading the thread I was thinking that what I like with pragmas  
is that
they are not macros. (I feel that macros is orthogonal with the  
syntax of Smalltalk
and could really open a big can of worms). :)

At the beginning when VW people introduced pragmas I was unconvinced  
and I hated
when vassili was using them to implement delegation in UI elements. I  
still hate the idea that
certain use of the pragmas can break all the tools with have and  
introduce a new semantics for delegation
(even if I like the way tweak use pragmas to register events. This is  
really nice so I'm somehow contradicting
a bit myself here but this is the feeling I get).
Now after working a lot with pragmas I really like them as a  
declarative registration mechanism
that I can dynamically query from within the language itself even  
interactively.

For example the menus in VW are an example of such a registration  
mechanism.

Stef

I haven't been keeping track of this discussion and haven't looked into
the FFI/pragma/primitives issue at all (so feel free to ignore what
follows), but I would like to make a small comment based on my
experience in trying to simplify programming languages (Smalltalk in
particular). One way to do things is to define a syntax to embed in the
source messages to be sent to the compiler object itself. So something
like

<primitive: 32> blah blue

would cause the expression between < > to be compiled separately and
executed as if it were "thisCompiler primitive: 32". The compiler is
free to do whatever it wants (this is the "object way") and then it can
continuing parsing the rest of the text. Adding methods to Compiler will
automatically extend what it can do without having to mess with the
parser.

Some people would like for Smalltalk to be much more declarative (the
bane of "doIts"!) and this proposal goes in the opposite direction. It
actually has a Forth-like flavor to it. But if you want simplicity, this
is one way to get it.

-- Jecel

That's exactly what Lukas did propose.
This imply that syntax inside angle brackets follows Smalltalk Syntax (apart implied receiver).
Unfortunately this is not the case for FFI nor eventual other extensions like andrews sql: or any other external language interfacing...
Unless the un-smalltalkish syntax is quoted... in a string for example <cdecl: 'int myFunc()'>

But that breaks FFI backward compatibility.
Eventually a backward compatibility package and automatical syntax transformer could solve the compatibility/transition problem... But i did not ear any echo in favour of it...

Angle brackets are so far used in Smalltalk
- for glue with internal vm (primitive:)
- for glue with external libraries (FFI, DLLCC ...)
- for adding meta-level information (not code, rather pragmas), like this is a menu, this is an exception handler, this method should be called when...

Maybe as future interfacing glue with other languages like andrews' sql:

While primitives and pragmas follows easily Smalltalk syntax, that is not the case of external glue.
So how to have both a generic parser for pragmas and a generic parser for external glue without quoting?

Andreas proposed a compiler client registering mechanism so as to solve FFI/Compiler unmodularity.
I have not understood yet how Andreas proposition does solve generic pragmas (with muliple keywords and without the need to register...)
Maybe there is a solution: first keyword is checked against registry. If not registered, Smalltalk syntax is assumed so as to enable generic unregistered pragmas...
But the registering stuff would be used only for FFI by now... Is it really worth ?

Nicolas


Jecel Assumpcao Jr a écrit :

________________________________________________________________________
iFRANCE, exprimez-vous !
http://web.ifrance.com

Hi Andrew and all -

[Changing the subject to open a new line of argumentation. And if this
is getting to long for some skip to the end where there is a summary of
the main points]

Thanks for your post and the follow-on discussion. This was an
interesting and quite illuminating angle on this issue for me. You are
formulating many of my concerns in somewhat different ways which
(hopefully) will make it possible for me to get my arguments across in a
better way.

I'll go over the arguments individually, but as a high-level thought: I
think you're exactly right, and I wish I'd seen this before and I
learned something. Now let's go into some details:

1. Primitives and FFI specs aren't pragmas

As we both agree, they aren't. They generate code and that generated
code isn't optional. But it goes even further than that: While a pragma
(i.e., an optional meta-annotation) can be parsed without any further
impact, an FFI spec (or a primitive) simply *cannot* be interpreted
without additional support.

We had this example just a few days ago: Stef complained that what he
tried to do for puts() didn't work. The reason? The system tried to
interpret an FFI spec as a pragma simply because the FFI wasn't loaded.
And this wouldn't get better if the FFI would use "pragma format" -
quite to the contrary. What *would* have happened is that Stef would've
been left with a completely meaningless string. Do we *really* want
that? Do we really want that the compiler lets slip through what is
effectively unintelligible text?

Let me repeat: It is impossible to interpret an FFI spec correctly
without the FFI loaded. And attempt to do so by using pragma syntax will
only mask the problem making it even more complex for the user to
understand what is going wrong. In 3.8 such an unintelligible definition
simply isn't accepted, which is the right thing to do.

I'll also point out that Lukas definition of "A pragma is a message-send
composed of a selector and a literal array of arguments" defines form
without function which is fair for pragmas but not what primitives or
FFI-specs are. Just consider saying that "a primitive is a message-send
composed of a selector and a literal array of arguments". It doesn't
make sense, indeed this has *nothing* to do with a primitive's raison
d'etre (I'll come back to this in just a second).

2. The support cost is the same with or without pragmas

Lukas is making a point that the support cost is supposedly smaller
using "pragmas everywhere", i.e., that it is less work for compiler,
decompiler, tools. This is untrue - the support cost is basically the
same. Here is why:

First, let's consider the input side. Regardless of whether you write an
FFI spec in pragma format or not, it still needs to be parsed. The same
goes for Sql statements or whatever. It doesn't matter whether the parse
is simple or not, whether it's implemented as an extension method on the
parser or independently, the fact is it still needs to be parsed (twice
if it's in pragma format). Besides which there is also the issue of
semantic verification (which is used both in primitives and FFI specs).

Now, let's consider the output side. Here is one of my favourite quotes
of Lukas so far: "I do model primitives as pragmas." This is one of the
great (under)statements in this discussion because it acknowledges that
primitives really *aren't* pragmas (if they were you wouldn't have to
model them as such).

On the other hand the statement implies that there is an alternative
modelling technique (using pragmas) for the primitive that can be used
to simplify the tools (and I'm almost certain I would've gotten a
mouthful about how horrible a hack this is if I would've come up with
the idea...) But regardless, if that's true for primitives, why would it
be untrue for, say, FFI specs? It is trivial to imagine that we use an
FFIPragma (created by the FFI parser) which prints the FFI spec
accordingly when asked for it. Voila! No new decompiler or other tools
needed, no patches either, and yes, that way you could browse cdecl: and
friends just as well.

So that in effect, the support cost remains the same, pragma or not.

3. We are loosing one of the few extension points in Squeak.

Historically, the "escape syntax" using <> has been used as one of the
few available syntactical extension points to Squeak. By having pragmas
occupy this entire realm we're giving up one of the last true extension
points to Squeak. Any new experiment will now require major syntactical
changes instead of being able to hook into this particular extension
point. Any time that happens I think we should be very careful about
what we're giving up.

4. Where to go from here?

I think that point 1) alone illustrates quite clearly why syntactical
extensions like the FFI should be treated as what they are: Syntactical
extensions. If text cannot be interpreted correctly by the compiler
(because for example there is support code missing which makes the text
intelligible) it should not be accepted. Everything else is a recipe for
confusion and disaster. This not only holds for the FFI but for *any*
kind of non-optional, code-generating (or -affecting) syntactical extension.

Because of that, I do indeed very much like Andrew's suggestion to mark
pragmas clearly and visibly. One of the additionals reasons being that
although compatibility with VW pragmas is *claimed* as far as I
understand from the follow-on discussion it is not actually *achieved*,
due to the need to declare pragmas in VisualWorks. Such that using a
properly declared #pragma:-pragma in VisualWorks would actually achieve
that compatibility.

Now, having used pragmas (in the real sense) quite extensively myself I
can see Andrew's original proposal backfiring right at me: What about
all of these pragmas we're already using? The best way I can think of
solving this problem would be by declaring them, too. This goes back to
my previous proposal, where it is easy to see how you would declare any
particular desired extension as simply being a "standard pragma" and let
the compiler deal with it. So that if you're a lazy guy you could use
<pragma:value:> without declaring pragmas specifically and <foo:bar:>
would have to be declared.

To summarize my main points:
1. Primitives, FFI-specs and some other extensions aren't pragmas.
Treating them like pragmas is ignoring their entire raison d'etre.
2. Unintelligible code should never be accepted by the compiler and we
should make sure that syntactical extensions (FFI, Sql and other) are
clearly marked as such.
3. The support cost is effectively the same regardless of whether using
pragmas or syntax extensions.
4. There is nothing wrong with other extensions being "modeled" as
pragmas to support the tools.
5. The <> escape syntax is one of the few extension points in Squeak.
Loosing it is a shame.
6. Declaring pragmas could combine both approaches: Leave room for
syntactical extensions but also make it possible to use "simple pragmas"
easily.

Cheers,
   - Andreas

Heh. Here is yet another interesting data point in this discussion. I
just went ahead and implemented an FFIPragma just like I mentioned
before (I'm attaching the changes because they are so hillariously
simple). It does everything I promised (printing, decompile, browsing
etc) BUT there is this interesting issue that because of the way the
compiler got changed, an FFI method now prints like here:

apiDeleteDC: aHDC
        <apicall: bool 'DeleteDC' (Win32HDC) module: 'gdi32.dll'>
        <primitive: 120>
        ^ self externalCallFailed

How come? Because the parser currently only picks up primitives if they
are registered as pragmas (see pragmaPrimitives). And so, although an
FFI call *implies* a primitive this primitive should really never be
exposed via pragmas. This is equivalent to "quick" primitives which
don't (and shouldn't) show up either.

Which illustrates once more that a primitive isn't a pragma and cannot
be treated as one.

Cheers,
   - Andreas

> > <1> and the FFI syntax don't comply to this definition.
>
> If that is the definition, then aren't  <+ 2>  , << 'a'>  and  <> 4> also
> pragmas?
> It would be nicely consistent if they were.

I should try to be more precise: "A pragma is a message-send composed
of a **unary** or **keyword** selector and a literal array of
arguments."

I implemented it yesterday in the train. It makes the implementation
even simpler and uses the same code to correct the selector if unknown
as for normal message sends. I will submit the fix soon on mantis.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

On 8/19/06, Andreas Raab <[hidden email]> wrote:
I was suggesting to fix that and allow other packages to register
their own primitives in the compiler. As explained in my initial mail
this would work perfectly with the Squeak primitives, but not with FFI
as they have a rather strange syntax.

> Which illustrates once more that a primitive isn't a pragma and cannot
> be treated as one.

Nice counter example. Thank you very much for providing it.

If I could do the suggested change to the compiler your example would
work nicely. You change-set still patches the compiler and therefor
introduces this kind of problems. The solution I proposed we would
have only one Pragma in the FFI method, namely #apicall:module:.
Therefor it would also build, decompile, syntax-highlight correctly.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

On Sat, 19 Aug 2006 05:24:03 +0200, Andreas Raab wrote:
...
> 5. The <> escape syntax is one of the few extension points in Squeak.  
> Loosing it is a shame.

I think that this is the main point, around which the various proposals  
can be arranged (if I overlooked or did not subsume someone's proposal,  
please tell me so):

[Andreas] the <> escape syntax serves existing extensions and there is no  
reason to break compatibility

[Lukas] everything in the <> escape is like a pragma and the associated  
tools (compiler, decompiler, debugger, "executor") must register their  
support, including the existing ones

[Jecel] whatever is in the <> escape shall be formulated as (if it not  
already is) a message and sent to the compiler (my favorite, just in case  
someone asks :)

There is not much which can be factored from these three directions?

/Klaus

P.S. I urge everybody interested in this thread to study  
#externalFunctionDeclaration in Andreas' FFIPragmaTest.1.cs, for getting  
an idea how an untyped system supports typed language (typed language  
extensions). And this example is only for the single [and naive!], not  
multiple and not the general, typed language(s) extension </grin>

Hi Lukas,

----- Original Message -----
From: "Lukas Renggli" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Saturday, August 19, 2006 9:49 AM
Subject: Re: Re: Re: Pragma syntax


> > > <1> and the FFI syntax don't comply to this definition.
> >
> > If that is the definition, then aren't  <+ 2>  , << 'a'>  and  <> 4> also
> > pragmas?
> > It would be nicely consistent if they were.
>
> I should try to be more precise: "A pragma is a message-send composed
> of a **unary** or **keyword** selector and a literal array of
> arguments."

But, why is that the definition? Why not binary selectors? Is it...
    because VW doesn't allow binary selectors?
    because the grammar would become ambiguous?
    the free stuff (searching for senders) wouldn't work with binaries?
    nobody suggested it?
    considered unnecessary?

I can't think of a good reason not to allow binary selectors, unless there is a
fundemental problem that can't easily be solved.

Excellent. I'll test it out once it's there.
Cheers,
Andy

>
> Cheers,
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
>

On 19 août 06, at 05:24, Andreas Raab wrote:

> 3. We are loosing one of the few extension points in Squeak.
>
> Historically, the "escape syntax" using <> has been used as one of  
> the few available syntactical extension points to Squeak. By having  
> pragmas occupy this entire realm we're giving up one of the last  
> true extension points to Squeak. Any new experiment will now  
> require major syntactical changes instead of being able to hook  
> into this particular extension point. Any time that happens I think  
> we should be very careful about what we're giving up.

Why you can pass a string? It will not be validated but you get your  
extensibility.

Stef

Hi Andreas,
Thanks for such a detailed exposition. I'll comment on just one point, and maybe
come back to the others when I've given them more thought.

..snip....

If the syntax of pragmas in VW had been different, e.g. << a: #b >>, then most
of these problems would go away. We would simply copy the VW syntax, and
pragma-statements would be entirely separate from compiler extension statements
<...>. If that were the situation, then I don't think that many would argue that
Squeak should give up compatibilty with VW and use <..> for pragma statements.
It is the overloading of <..> which causes the problems.
How would it be if a self-declaring pragma statement had syntax <<..>> , whereas
a pre-declared pragma name had the VW syntax <...>   ? Code is compatible with
VW, which requires pragmas be declared before use, and we don't lose the ability
to compile pragmas without declaring in advance.

The VW pragma declaration statement <pragmas: #class> etc. would also require
the #pragmas: pragma name to be bootstrapped somehow, and pre-declared in
ProtoObject, or wherever.

The <<..>> syntax is equivalent to the <pragma: ...> syntax I suggested
previously, but more readable, less verbose, and doesn't prevent <pragma: ..>
from being used elsewhere. It could be viewed as "an unnamed compiler extension
which parses an enclosed pragma statement" i.e.
    <<a: 1>> is equivalent to <   <a:1>    >

I have deliberately avoided the question of how compiler extensions are
installed, and which compiler extension is used by the compiler for a particular
<...> expression.

I am not sure I'm entirely comfortable with this as a solution, but would like
to hear what people think ?

Cheers,
Andy

..snip...

On 19 août 06, at 13:49, stéphane ducasse wrote:

Or you could even parse the string separately.
I do not see the difference except that the string is the argument of  
a <jlk:

But why? seriously I do not understand why overloading  of <...> is a  
problems.
Why the compiler cannot query <primitive: > and do something specific  
with it
and query <ffi: module:> and do something else and not query  
<myOwnPragmas:...>

I would really like to know.

stef

Hi Stef,
----- Original Message -----
From: "stéphane ducasse" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Saturday, August 19, 2006 1:03 PM
Subject: Re: Syntactical extensions vs. pragmas everywhere


I don't think that overloading <...> is a problem, at least for this particular
part of the discussion.

> Why the compiler cannot query <primitive: > and do something specific
> with it
> and query <ffi: module:> and do something else and not query
> <myOwnPragmas:...>

It will have to do something like that, regardless of how it is implemented.

The question is whether <ffi: ... module: ...> means this...
    1. "If FFI is loaded, then compile using FFI, else compile as a pragma"
or this...
    2. "If FFI is loaded, then compile using FFI, else compilation error (the
method doesn't compile)"

If FFI isn't loaded, then why does the compiler know enough about it to query
for its existence?
What about other, optional, compiler extensions which use <...>?
Should the compiler know about all those as well? The answer is probably, but
not necessarily, no.

So we are left with <x: y:> meaning either...
    3. "If there is an extension (E) for x:y: , then compile using E, else
compile as a pragma.
 or
    4. "If there is an extension (E) for x:y: , then compile using E, else
error"

3. means that you will always get a pragma and no compilation error. If the
extension (E) was missing at compilation time, then the method will execute the
code following the <..>. So it might throw an error, or run a slow version of
what <x:y:> would have done, or something else. Failing to compile might be
preferable.

4. means that "ordinary" pragmas will fail to compile, because there is no
extension for <A>, or <B>, or <myPragma> etc. So that is not an option.

Is there a way to achieve 4., but whilst allowing "ordinary" pragmas to still be
compiled?

    a. Use syntax to distinguish "ordinary" pragmas from "code" pragmas
        a.1.
            <<A>> , <pragma: A> , etc.
            "ordinary pragmas are tagged - but this is incompatible with VW"

        a.2.
            <FFI cdecl: ...> <SQL ...> etc.
            "extensions are tagged - but this breaks existing FFI syntax"

    b. record valid "ordinary" pragma names elsewhere.
        As in VW, where pragmas are declared before use.

    c. Write extensions that use a syntax which cannot be compiled as a pragma,
thus forcing compilation failure when the extension is missing. Similar to a.2.
         e.g. <x: 1 y: 2  ****>
        But this only works if the compiler doesn't insist that the <..>
expression MUST be a pragma before passing control to the extension.

It's fascinating stuff !

Cheers,
Andy
>
> I would really like to know.
>
> stef
>
>

Hi Andrew,

> But, why is that the definition? Why not binary selectors? Is it...
>     because VW doesn't allow binary selectors?

No. I don't know if binary selectors are allowed in VW.

>     because the grammar would become ambiguous?

Yes. For example this would be ambigous to parse: <>1> (the pragma
with the selector #> and the arguments #(1)) or <=#foo> (the pragma
with the selector #= and the arguments #(foo)).

>     the free stuff (searching for senders) wouldn't work with binaries?

No.

>     nobody suggested it?

No.

>     considered unnecessary?

No, but frankly I can't think of an example where this would make
sense. The pragmas I have in mind and those that I have seen in other
people's code are not mathematical operators. Maybe you can provide an
example where this would be useful?

Note 1: I see the pragma selector as a message that can be sent to an
object to configure it somehow, binary selectors usually have a
slightly different meaning.

Note 2: It would be easy to allow pragmas like this <* 6>, <,
'world'>, basically one line of code that needs to be updated.

> Excellent. I'll test it out once it's there.

I published it to http://source.squeakfoundation.org/inbox, please
have a look. The tests do all run, I only changed one method that does
the parsing of the selector. The correction algorithm is the same as
the one used to correct selectors of normal message sends in your
code.

-----------------------------------------------

Name: Compiler-lr.54
Author: lr
Time: 19 August 2006, 5:09:02 pm
UUID: 9ea70c0b-1ebc-4d35-b9f2-bfa1e5e57f8d
Ancestors: Compiler-md.53

- offer to correct pragma message selectors if they are unknown to the system

-----------------------------------------------

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch