Tx I will have to digest that.

Stef

On 19 août 06, at 16:39, Andrew Tween wrote:

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