An alternative FFI/Parser proposal

stéphane ducasse ducasse at iam.unibe.ch
Thu Aug 17 07:26:37 UTC 2006


Tx for discussing with us.
I like this kind of email much better than the other one and I will  
let lukas discusses the discussed points.

Stef

On 17 août 06, at 08:43, 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. 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
>




More information about the Squeak-dev mailing list