> We're making progress. Now that we've agreed on one key point let's go
> to another. Under the assumption that FFI specs are pragmas it is pretty
> clear that they should be in pragma format. Agreeing that they aren't
> means that they *can* be but that they don't have to be (which is a much
> weaker statement). I think you're trying to say the same by saying "they
> are *ideally* parsed and created using pragmas". It seems to me we're
> both agreeing that while it may have advantages to use pragma format
> where possible (like for primitives) there is certainly no requirement
> for that from a consistency perspective. Do we agree on that, too?

Yes, we agree: FFI declarations can be pragmas, but they don't have to
be. This is the status quo in 3.9.

Pragmas works well and they are well tested. There were no bug reports
or complaints as far as I know. I am using them daily. In the process
of this discussion I even improved the parsing of pragma selectors by
adding validation and auto-correction. So there is a valuable gain in
that area.

My initial goals were different though:

1. Simplify the parser, compiler, decompiler, syntax-highlighter,
auto-completor, editor, ... tool-chain by unifying the parsing of
pragmas, primitives and FFI calls.

2. Enhance the compiler, so that it can be easily extended without
having to patch its core methods. In other words: fully use the
existing pragma implementation in the compiler to turn the compiled
methods into a primitive or FFI call, if a defined meta-definition
(pragma) is given.

3. Give pragmas an easily understandable syntax that everybody can
trust on, that can be easily explained to newcomers and that give no
surprises if new packages are loaded. Personally I find it rather
strange to have a have a half-backed C declaration being parsed with a
Smalltalk parser.

> This isn't about reserving "super secret" selectors. This is about the
> compiler being able to tell you "hey, you're missing something
> big-time". And most of the time it won't be super-secret but rather
> fairly well-known (like "dude - you need the Sql parser if you want to
> use Sql statements") where when you see it you'll slap your forehead and
> say "duh".

If you want to be extensible you cannot know all the possible
extensions in advance. This is the whole point of extensiblilty.
Therefor it doesn't make sense to say "hey dude, you need extension XY
if you want to use this selector". Moreover the same selector might
mean something completely different in your context (image) than it
does in mine.

Cheers,
Lukas

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