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