Email list hosting service & mailing list manager

posix-error and a list of scheme procedure arguments Shiro Kawai (15 Aug 2020 07:54 UTC)
Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen (15 Aug 2020 11:16 UTC)
Re: posix-error and a list of scheme procedure arguments Lassi Kortela (15 Aug 2020 12:09 UTC)
Synthetic errno values Lassi Kortela (15 Aug 2020 13:10 UTC)
Re: Synthetic errno values John Cowan (15 Aug 2020 15:19 UTC)
Re: Synthetic errno values Lassi Kortela (15 Aug 2020 15:34 UTC)
Re: Synthetic errno values hga@xxxxxx (15 Aug 2020 16:02 UTC)
Re: Synthetic errno values Lassi Kortela (16 Aug 2020 07:58 UTC)
Re: Synthetic errno values hga@xxxxxx (16 Aug 2020 12:39 UTC)
Re: Synthetic errno values Lassi Kortela (16 Aug 2020 13:07 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 01:11 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 02:30 UTC)
Split SRFI 198 from generic debugging/inspection? hga@xxxxxx (16 Aug 2020 02:43 UTC)
Re: Split SRFI 198 from generic debugging/inspection? Lassi Kortela (16 Aug 2020 09:06 UTC)
Re: Split SRFI 198 from generic debugging/inspection? hga@xxxxxx (16 Aug 2020 13:01 UTC)
Matching what other languages give in SRFI 170 errors Lassi Kortela (16 Aug 2020 13:47 UTC)
Re: Matching what other languages give in SRFI 170 errors Marc Nieper-Wißkirchen (17 Aug 2020 06:11 UTC)
Re: Matching what other languages give in SRFI 170 errors Lassi Kortela (17 Aug 2020 10:10 UTC)
Re: posix-error and a list of scheme procedure arguments Göran Weinholt (16 Aug 2020 08:52 UTC)
Re: posix-error and a list of scheme procedure arguments Lassi Kortela (16 Aug 2020 09:01 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 09:10 UTC)
Re: posix-error and a list of scheme procedure arguments Göran Weinholt (16 Aug 2020 09:40 UTC)
Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen (16 Aug 2020 10:20 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 11:29 UTC)
Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen (16 Aug 2020 12:18 UTC)
Continuation marks and SRFI 198 Lassi Kortela (16 Aug 2020 11:29 UTC)
Re: Continuation marks and SRFI 198 Marc Nieper-Wißkirchen (16 Aug 2020 12:51 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 11:17 UTC)
Passing symbols to say where errors came from? Lassi Kortela (16 Aug 2020 11:21 UTC)
Re: Passing symbols to say where errors came from? John Cowan (17 Aug 2020 17:06 UTC)
Re: Passing symbols to say where errors came from? hga@xxxxxx (17 Aug 2020 18:43 UTC)
Re: Passing symbols to say where errors came from? Shiro Kawai (17 Aug 2020 22:05 UTC)
Re: Passing symbols to say where errors came from? Marc Nieper-Wißkirchen (18 Aug 2020 06:09 UTC)

Re: posix-error and a list of scheme procedure arguments Göran Weinholt 16 Aug 2020 09:40 UTC

Shiro Kawai <xxxxxx@gmail.com> writes:

> The thing is that Gauche aims at a hybrid of Scheme and general
> list-processing library in C; C API can be called from other C
> functions unrelated to Scheme.
>
> The bottom error handler can examine the Scheme VM state and get info
> from the top frame in the stack. But it isn't necessarily the Scheme
> procedure related to the C API, for the Scheme procedure may be tail
> called, in that case we don't have a frame for it at the time the C
> API is called.

Gauche is not alone in having this kind of structure, which does make it
difficult to make a systematic implementation of SRFI 198. Maybe it's
possible in Gauche with some effort, but e.g. Chez Scheme and Guile can
also mix Scheme and C code, and I find it unlikely that those
implementations would get a systematic SRFI 198 implementation that
covers all foreign errors.

> There's a couple of choices---change all the C API to take some Scheme
> context info (we can reference the current Scheme VM info, but that's
> not enough because of the tail-call problem), or wrap low-level calls
> in srfi-170 to prevent tail-calling bottom-level API.

Is the scope of the problem to solve this for only SRFI 170? If I were
to implement SRFI 170 for Chez then I'd write new C wrappers for each
required C library function, and call them via the FFI. The wrappers
would return the return value & errno to Scheme code, which would then
call SRFI 198 as required. Maybe I'm not seeing something, but is your
problem related to trying to reuse the existing C functions in Gauche
that raise errors themselves?

--
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK