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....

> 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.

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...