Re: Video on continuations, and call/cc-safe programming in the SRFI Marc Nieper-Wißkirchen (17 Aug 2022 19:58 UTC)
Re: Video on continuations, and call/cc-safe programming in the SRFI Marc Nieper-Wißkirchen (18 Aug 2022 14:57 UTC)
Re: Video on continuations, and call/cc-safe programming in the SRFI Marc Nieper-Wißkirchen (11 Sep 2022 07:32 UTC)
Re: Video on continuations, and call/cc-safe programming in the SRFI Marc Nieper-Wißkirchen (11 Sep 2022 17:59 UTC)
Re: Video on continuations, and call/cc-safe programming in the SRFI Marc Nieper-Wißkirchen (11 Sep 2022 18:25 UTC)
Re: Video on continuations, and call/cc-safe programming in the SRFI Marc Nieper-Wißkirchen (12 Sep 2022 17:33 UTC)
Re: Video on continuations, and call/cc-safe programming in the SRFI Marc Nieper-Wißkirchen (14 Sep 2022 06:48 UTC)
Re: Video on continuations, and call/cc-safe programming in the SRFI Marc Nieper-Wißkirchen (17 Sep 2022 15:51 UTC)
Re: Video on continuations, and call/cc-safe programming in the SRFI Marc Nieper-Wißkirchen (20 Sep 2022 06:33 UTC)

Re: Video on continuations, and call/cc-safe programming in the SRFI Marc Nieper-Wißkirchen 18 Aug 2022 14:57 UTC

Am Do., 18. Aug. 2022 um 16:50 Uhr schrieb Bradley Lucier
<xxxxxx@math.purdue.edu>:
>
> On 8/17/22 3:58 PM, Marc Nieper-Wißkirchen wrote:
> > ---- External Email: Use caution with attachments, links, or sharing data ----
> >
> >
> > Wouldn't it be enough to say that a "pure" (= "call/cc-safe"
> > procedure) is a procedure that behaves as if doesn't mutate any
> > location in the store?
> >
> > The only locations visible by the rest of the program are those
> > created outside the "pure" procedure, the locations referenced by the
> > procedure's return values, and the locations referenced by the
> > arguments and continuation passed to its call-back arguments. So a
> > "pure" procedure must not change these locations (or, if it does so,
> > must reset them to their old values before control leaves its code).
> >
> > Just saying that the locations captured by reifying the current
> > continuation are not mutated is not enough. On the other hand, the
> > above definition includes the captured stack.
> >
> > Marc
>
> I prefer what I've said in the document, as I don't understand all the
> implications of what you've written here.
>
> Brad

Can you be more precise about what you don't understand what I have
written? Unless I have written nonsensical stuff (which, alas, happens
from time to time), I should be able to explain it.