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: Continuation marks and SRFI 198 Marc Nieper-Wißkirchen 16 Aug 2020 12:51 UTC

Am So., 16. Aug. 2020 um 13:30 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> > 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.

One could perceive a higher-level API that allows a poor man's
implementations for systems not (yet) having continuation marks:

(call/who WHO PROC ARGS ...) and (apply/who WHO PROC ARGS ...)

would call (apply) the procedure PROC with the args ARGS ... In the
dynamic extent of the call, (who) would return WHO (and we would have
similar getters for PROC and ARGS ...). This can be emulated with
"parameterize".

We can even have shortcut macros (call/ PROC ARGS) and (apply/ PROC
ARGS) that expand into (call/who 'PROC PROC ARGS ...) and (apply/who
'PROC PROC ARGS ...)