To be honest, while I perfectly understand that my proposal is 
imperfect, I'm not the person who has to prove anything here. I'm 
defending the status quo and all that my proposal is doing is to point 
out that there is absolutely no need to change the FFI syntax.

You are free to take the proposal apart to your hearts content but be 
aware that this is one that actually has my support and that a proposal 
that breaks the FFI will in all probability not get my support and 
therefore be an uphill battle, since I *will* make sure that the 
interests of the current users of the FFI are adequately represented in 
this discussion.

In other words, propose an alternative.

Cheers,
   - Andreas

Lukas Renggli wrote:
>> A good way of dealing with these differences would be if a client could
>> register specific pragmas which are parsed in a client dependent manner.
>> So that, for example, the FFI would register <apicall:> and <cdecl:> for
>> FFI specs and Tweak may register <on:> for parsing method triggers[*].
>> In this case, Parser could simply invoke the proper client for a
>> registered pragma, pass it a stream and let it decide what to do. Given
>> a sufficient interface for client and Parser, this would leave the
>> entire responsibility with the client instead of Parser, but Parser
>> could still provide a default implementation.
> 
> Nice idea, though ...
> 
>> Unfortunately, there are also a couple of gotchas with the proposal:
> 
> + support for different parser/compiler will be difficult
> + breaks encapsulation of the parser/compiler
> + de-compilation won't work out-of-the-box
> + inconsistent syntax: the current FFI syntax makes no sense, it is
> neither valid C nor valid Smalltalk code, I suspect it was done like
> this to simplify the parsing)
> 
> Cheers,
> Lukas
>