Email list hosting service & mailing list manager

posix-error and a list of scheme procedure arguments Shiro Kawai (15 Aug 2020 07:55 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:12 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:44 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:55 UTC)
Re: posix-error and a list of scheme procedure arguments Lassi Kortela (16 Aug 2020 09:02 UTC)
Re: posix-error and a list of scheme procedure arguments Shiro Kawai (16 Aug 2020 09:11 UTC)
Re: posix-error and a list of scheme procedure arguments Göran Weinholt (16 Aug 2020 09:44 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:52 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:07 UTC)
Re: Passing symbols to say where errors came from? hga@xxxxxx (17 Aug 2020 18:44 UTC)
Re: Passing symbols to say where errors came from? Shiro Kawai (17 Aug 2020 22:06 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