Syntactic closures and phasing Marc Nieper-Wißkirchen (19 Nov 2021 09:06 UTC)
Re: Syntactic closures and phasing Arthur A. Gleckler (07 Jan 2022 16:47 UTC)
Re: Syntactic closures and phasing Shiro Kawai (07 Jan 2022 18:35 UTC)
Re: Syntactic closures and phasing Shiro Kawai (07 Jan 2022 19:48 UTC)
Re: Syntactic closures and phasing Marc Nieper-Wißkirchen (08 Jan 2022 08:48 UTC)
Re: Syntactic closures and phasing Shiro Kawai (08 Jan 2022 09:13 UTC)
Re: Syntactic closures and phasing Marc Nieper-Wißkirchen (08 Jan 2022 10:13 UTC)
Re: Syntactic closures and phasing Marc Nieper-Wißkirchen (11 Mar 2022 17:41 UTC)
Re: Syntactic closures and phasing John Cowan (11 Mar 2022 19:41 UTC)
Re: Syntactic closures and phasing Marc Nieper-Wißkirchen (12 Mar 2022 09:08 UTC)
Re: Syntactic closures and phasing John Cowan (08 Jan 2022 01:24 UTC)
Re: Syntactic closures and phasing Marc Nieper-Wißkirchen (08 Jan 2022 08:54 UTC)

Re: Syntactic closures and phasing Marc Nieper-Wißkirchen 08 Jan 2022 08:48 UTC

Dear Shiro,

thanks for chiming in!

Am Fr., 7. Jan. 2022 um 20:48 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> Regarding phase separation:
> With low-level macros, it is possible for the users to write code to capture continuation within the expander and save it somewhere, and invoke it at runtime.  To some extent, we need to rely on users not to carry things across phase boundaries except the syntactic forms defined by the protocol.  We can only warn users about common pitfalls.  Can this sc case be also one of such "things you should avoid"?

A Scheme system should catch such a continuation capture. That's one
reason why SRFI 226 defines continuation barriers. With them, one can
prohibit downward jumps across well-defined boundaries.

[...]

Marc