More JNI vs. Pika comparison Jim Blandy (17 Feb 2004 23:22 UTC)
Re: More JNI vs. Pika comparison Matthew Dempsky (18 Feb 2004 08:09 UTC)
Re: More JNI vs. Pika comparison Jim Blandy (18 Feb 2004 08:39 UTC)
Re: More JNI vs. Pika comparison Matthew Dempsky (18 Feb 2004 15:46 UTC)
Re: More JNI vs. Pika comparison Tom Lord (20 Feb 2004 17:32 UTC)
Re: More JNI vs. Pika comparison Jim Blandy (24 Feb 2004 22:13 UTC)
Re: More JNI vs. Pika comparison Tom Lord (24 Feb 2004 22:32 UTC)
Re: More JNI vs. Pika comparison Jim Blandy (24 Feb 2004 23:23 UTC)
Re: More JNI vs. Pika comparison Tom Lord (25 Feb 2004 00:16 UTC)

Re: More JNI vs. Pika comparison Jim Blandy 18 Feb 2004 08:38 UTC

Matthew Dempsky <xxxxxx@flame.org> writes:
> Jim Blandy <xxxxxx@redhat.com> writes:
>
> > I've come across a situation which is reasonably straightforward to
> > handle in a JNI-style interface, but which I think requires machinery
> > I haven't seen yet in Pika-style.  I'd like to see the Pika folks'
> > solution here.
>
> Well, I'd personally make a call to scm_reader, but then I think
> that's avoiding the greater issue at hand you're referring to -- that
> of automatically generating Pika-FFI-aware code with third-party
> tools.

Or you could stick to Bison if you wanted --- a grammar for Scheme
data was what I had in hand, but one might want to use Bison for
parsing strings in some non-Scheme-related grammar, too.

> I'm not too familiar with Bison, so answer this for me: with Bison's
> calling conventions for parsing, how does it handle run-time errors?
> e.g. if I write a grammar rule that tries to open a file and gets an
> error or tries to allocate memory when none is available, how is this
> error propogated if at all?

There are special statements like 'YYABORT;' and 'YYACCEPT;' that you
can use in semantic actions to exit the parser non-locally in various
ways.  In info, see '(bison)Action Features'.

Why?