Lukas Renggli wrote:
>> 1. Primitives, FFI-specs and some other extensions aren't pragmas.
>> Treating them like pragmas is ignoring their entire raison d'etre.
> 
> I've never said primitives or FFI specs **are** pragmas, I only said
> that they are ideally parsed and created using pragmas. It is solely a
> compile-time thing, after that you have your compiled method.
> Everything else doesn't make sense and you know that.

Ah, good. I was honestly not sure if this was what you meant. From my 
POV it seemed as if you really think that primitives *are* pragmas and 
that therefore FFI specs *should be* pragmas, too. I completely disagree 
with that but as a position it's consistent that's why I spent that much 
time on making clear that FFI specs are not pragmas.

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?

>> 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.
> 
> I would also like to reserve a couple of selectors for special pragmas
> as well as some message selectors in Object. The compiler should
> prevent other people to use those selectors as long as my super secret
> package is not loaded. These selectors belong to me and nobody should
> accidently use or call them. I am the owner of those selector. Keep
> away. ;-)

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

>> 5. The <> escape syntax is one of the few extension points in Squeak.
>> Loosing it is a shame.
> 
> You can still change the parser class for your own classes. This is a
> much better extension point than to extend it by patching the parsers
> (old parser, new parser, refactoring parser), decompilers,
> syntax-highlighters, code competition engines, etc.

I disagree. The FFI is a great example for it - yes you could make it so 
that the specs only work in subclasses of ExternalLibrary (IIRC, VW does 
it that way) but it is really, really inconvenient from the user 
perspective. The <> extension point is in particular useful if you have 
a need to do extensions across the class hierarchy. Since I've used 
both, I can testify that they both have their uses and those uses differ 
significantly.

Cheers,
   - Andreas