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 Matthew Dempsky 18 Feb 2004 08:09 UTC

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.

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?

(At first glance, it looks like Bison supports no such mechanisms, but
I'll leave it to someone more experienced to make such accusations.
Also, note I'm referring to the semantics generating an error, not the
syntax.)

-jivera