An alternative FFI/Parser proposal
Klaus D. Witzel
klaus.witzel at cobss.com
Thu Aug 17 07:50:09 UTC 2006
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
>
>
More information about the Squeak-dev
mailing list
|