[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More JNI vs. Pika comparison

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.

Matthew Dempsky <jivera@xxxxxxxxx> writes:
> Jim Blandy <jimb@xxxxxxxxxx> 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'.