Klaus D. Witzel wrote:
> 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).

Yes that would be nice. Got some time to spend on it? ;-)

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

Yes, that would be the nicer solution if parsers can agree on a common 
protocol. However, I'm not sure that's doable (and it seemed to 
complicate the overall Gestalt of the proposal) so that in the mindset 
of proposing the simplest thing that all parties could agree on I just 
proposed a plain input stream.

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

I don't understand what you mean by that. In which way would the user 
decide "how to use FFI"?

>> If anyone were to implement that proposal it would certainly find my 
>> support.
> 
> After all this embarrassment which was already exchanged?

I have said from my first post that changing the FFI syntax is out of 
the question but that I'm open to discuss any alternatives. Nothing has 
changed from that.

Cheers,
   - Andreas