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

Continuation marks and SRFI 198 Lassi Kortela 16 Aug 2020 11:29 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".

That sounds great.

SRFI 198 and 170 need to be usable even on tiny Schemes, so 198 must be
able to provide all the usual features without continuation marks. Even
it seems wise to make retrieving the Scheme procedure name optional, it
would be nice to store it in a way that works even without continuation
marks, simply by the implementation manually storing a symbol in the object.

However, tying 198 seamlessly into a continuation marks system would
definitely be the right thing. Marc, can you suggest us an API for that?
I for one won't be able to learn the topic fast enough.