> Yes. But, there are some potential drawbacks...
>     1. I cannot write an extension which uses a name that is already in use by
> the Parser.
>         e.g. #notify: , #parse:class: etc.

Yes, but these methods need to be tagged, so the parser/compiler knows
that these should be called after compilation. All others pragma
selectors would remain unused and left for interpretation by your
application.

>     2. It might be a dangerous thing to use one of the method names defined in
> Parser's superclasses. e.g. #error:

I think it might make sense to call these methods on the parser, but
it could be any other class. It just needs to be a fixed place.

>     3. No keyword methods can safely be added to the Parser in the future. The
> new method's name might already be in use by an extension. A change to the
> parser's interface (i.e. the selectors it implements/understands) could result
> in an extension, and/or, the parser breaking.
>
> Please see my post in the 'Re: An alternative FFI/Parser proposal' thread for a
> possible alternative arrangement. What do you think?

I don't see a point in widening the allowed syntax within the angle
construct. Right now a pragma is using existing Smalltalk construct
that every newcomer can understand and use. Allowing different
syntaxes complicates things in different areas. The Smalltalk syntax
should remain minimal, and not get bloated with new things that nobody
will understand. There are already many examples where languages got
destroyed by adding XML, SQL, HTML, ... to the language itself.
Smalltalk provides different and better ways to change/extend its
language.

To summarize, these are basically two different views:

(1) Pragmas as a syntax extension, where on can put almost anything
between the angle brackets after an initial keyword selector defining
the syntax.

(2) Pragmas as a message send with literal arguments.

I am for the simple and powerful. And this is (2) in my opinion.

Cheers,
Lukas

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