Hi Folks -

Regardless of Stephane's insults I'm actually interested in making 
progress on the issue of how to integrate the FFI into the parser in 
general. So here is an alternative proposal:

Instead of insisting that the FFI syntax needs change, let's assume that 
there may be differences in the pragma formats. That has been true in 
the past and in my experience it is likely that it will be true and 
valuable in the future, too (like for example, if somebody wants to use 
blocks in a pragma).

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.

[*] The main reason for Tweak to parse triggers separately is to provide 
semantic checks. For example, the <on: event in: signaler> annotation 
requires the signaler to be a field of the receiver. Being able to hook 
into the parse in this way can be useful for other kinds of semantic 
assertions.

Unfortunately, there are also a couple of gotchas with the proposal: 
Most importantly, it requires that any parser can hand off the current 
input stream to a client and continue after it's getting the stream 
back. Not sure if all parsers could easily do that. In addition, the 
client would need to have sufficient access to the parser to perform 
whatever action it requires, including (potentially) correction or error 
handling. This may be tricky since the existing parsers have no common 
protocols for that. Lastly there is an issue with what exactly should 
happen if we're trying to parse a pragma but lack the proper support 
(like parsing an FFI spec without the FFI being present). I'd rather 
have it if that the parser is aware of such problems and can raise an 
error instead of trying to get the user to use something that won't work 
anyway, but this may not be possible.

In any case, this is a clear alternative that offers the same benefits 
of the original proposal ("clean", "extensible") while avoiding 
fundamentally breaking the FFI for no good reason. If anyone were to 
implement that proposal it would certainly find my support.

Cheers,
   - Andreas