Syntactical extensions vs. pragmas everywhere
andreas.raab at gmx.de
Sun Aug 20 19:38:57 UTC 2006
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
>> 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
More information about the Squeak-dev