On Thu, 17 Aug 2006 08:43:04 +0200, Andreas Raab wrote:

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

Nice if it would also provide some support for Lukas' suggestion, IMO.  
Being able to browse senders of #apicall: and #cdecl: (e.g. any such  
construct) is definitively an advantage (a free beer). Try this in Java ;-)

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

I can already see all the skip: -2's when the stream is passed ;-) How  
about passing an interface to parser (a specialized contract which  
delegates). That'd be a clean implementation.

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

Let the next user in her/his next project decide how to use FFI, how about  
that.

> If anyone were to implement that proposal it would certainly find my  
> support.

After all this embarrassment which was already exchanged?

/Klaus

> Cheers,
>    - Andreas
>
>