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?