Hi Stef,
----- Original Message ----- 
From: "stéphane ducasse" <ducasse at iam.unibe.ch>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, August 19, 2006 1:03 PM
Subject: Re: Syntactical extensions vs. pragmas everywhere


> >> 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.
>
> But why? seriously I do not understand why overloading  of <...> is a
> problems.

I don't think that overloading <...> is a problem, at least for this particular
part of the discussion.

> Why the compiler cannot query <primitive: > and do something specific
> with it
> and query <ffi: module:> and do something else and not query
> <myOwnPragmas:...>

It will have to do something like that, regardless of how it is implemented.

The question is whether <ffi: ... module: ...> means this...
    1. "If FFI is loaded, then compile using FFI, else compile as a pragma"
or this...
    2. "If FFI is loaded, then compile using FFI, else compilation error (the
method doesn't compile)"

If FFI isn't loaded, then why does the compiler know enough about it to query
for its existence?
What about other, optional, compiler extensions which use <...>?
Should the compiler know about all those as well? The answer is probably, but
not necessarily, no.

So we are left with <x: y:> meaning either...
    3. "If there is an extension (E) for x:y: , then compile using E, else
compile as a pragma.
 or
    4. "If there is an extension (E) for x:y: , then compile using E, else
error"

3. means that you will always get a pragma and no compilation error. If the
extension (E) was missing at compilation time, then the method will execute the
code following the <..>. So it might throw an error, or run a slow version of
what <x:y:> would have done, or something else. Failing to compile might be
preferable.

4. means that "ordinary" pragmas will fail to compile, because there is no
extension for <A>, or <B>, or <myPragma> etc. So that is not an option.

Is there a way to achieve 4., but whilst allowing "ordinary" pragmas to still be
compiled?

    a. Use syntax to distinguish "ordinary" pragmas from "code" pragmas
        a.1.
            <<A>> , <pragma: A> , etc.
            "ordinary pragmas are tagged - but this is incompatible with VW"

        a.2.
            <FFI cdecl: ...> <SQL ...> etc.
            "extensions are tagged - but this breaks existing FFI syntax"

    b. record valid "ordinary" pragma names elsewhere.
        As in VW, where pragmas are declared before use.

    c. Write extensions that use a syntax which cannot be compiled as a pragma,
thus forcing compilation failure when the extension is missing. Similar to a.2.
         e.g. <x: 1 y: 2  ****>
        But this only works if the compiler doesn't insist that the <..>
expression MUST be a pragma before passing control to the extension.

It's fascinating stuff !

Cheers,
Andy
>
> I would really like to know.
>
> stef
>
>