On Thu, 17 Aug 2006 10:16:27 +0200, Andreas Raab wrote:
> 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? ;-)

Sure, I have. But don't wait for it. ExternalObject and friends have  
priority 7 here (just one below InterpreterSimulator ;-)

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

NP (stream would be sufficient) but how about forcing parser packages to  
subclass the contract? The contract could take responsibility for FFI  
being present or not " parser notify: 'support for external objects not  
installed in your image' ".

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

I meant, the parser/compiler writer is a user and transitively so is the  
parser's user. If a parser/compiler package provided an alternative way to  
use FFI, that would be the choice I had in mind.

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

[OT] NP but this was not my point :|

/Klaus

> Cheers,
>    - Andreas
>
>