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 hga@xxxxxx 15 Aug 2020 10:57 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 hga@xxxxxx 15 Aug 2020 11:50 UTC
Re: posix-error and a list of scheme procedure arguments Lassi Kortela 15 Aug 2020 12:09 UTC
Re: posix-error and a list of scheme procedure arguments hga@xxxxxx 15 Aug 2020 12:42 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 hga@xxxxxx 16 Aug 2020 02:26 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 Marc Nieper-Wißkirchen 16 Aug 2020 10:20 UTC

The systematic way to maintain frame information is given by
continuation marks (Racket, SRFI 157, and Racket's modification of
Chez Scheme [1]). This is the portable equivalent to stack inspection
for languages with tail calls and call/cc ([2], [3], ...).

An elegant solution would be if SRFI 198 defines a continuation mark
key (see also the addendum to SRFI 157 in SRFI 154), whose value is
extracted whenever an error object is constructed. Such a key can
either be set with "with-continuation-mark", which works also in the
presence of tail calls and call/cc, or by the implementation whenever
a SRFI 170 procedure is being entered.

I understand that only a few Schemes support continuation marks yet,
but whatever solution will finally be proposed to SRFI 198, there
should be an upgrade path to the use of continuation marks, which is
"the right way".

Marc

--

[1] https://www.cs.utah.edu/plt/publications/pldi20-fd.pdf
[2] http://www.ccs.neu.edu/home/dherman/research/papers/scheme08-stack-marks.pdf
[3] https://www2.ccs.neu.edu/racket/pubs/esop2001-cff.pdf

Am So., 16. Aug. 2020 um 11:44 Uhr schrieb Göran Weinholt <xxxxxx@weinholt.se>:
>
> 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