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