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)
|
Am Sa., 8. Jan. 2022 um 10:13 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>: > > On Fri, Jan 7, 2022 at 10:48 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote: >> >> >> 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. >> > > Right. My point is that if we think it's up to the runtime to detect such bad usage, carrying an expand-time environment to a runtime environment can be thought the same. I will reply to your earlier post later. > As a spec, we have a choice that we say the implementation MUST detect such sase, or SHOULD, or let it be completely implementation-dependent. I think SHOULD be reasonable. R7RS would probably say "should", R6RS would probably say "must". For the user, it is more helpful if implementations detect such behavior and don't crash. If SRFI 226 is supported, it, therefore, makes a lot of sense in my opinion to force the installation of a continuation barrier.