PS One can also ask what happens to later returns if the result of an earlier return is modified. And, maybe, it is a good idea to even restrict to vector-map from the R6RS and R7RS base languages first and see how it can be implemented efficiently.

Am So., 20. Juni 2021 um 10:31 Uhr schrieb Marc Nieper-Wißkirchen <xxxxxx@gmail.com>:
Am So., 20. Juni 2021 um 09:36 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:


On Sat, Jun 19, 2021 at 8:59 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

But in what sense would the existence of, say, linear update procedures, drag the performance of code? You won't say that 'set!' or 'vector-set!' do this.

No, I meant that not being able to use linear update procedures in most of the places drag the performance, if we take a strictly restart-safe approach.  Just take vector-unfold.  To make it restart-safe, you can't use vector-set! in it, even though almost always the higher-order procedures won't return more than once.

Thank you for explaining. So we don't have to look as far as linear update procedures but can restrict our attention to the possibly more well-known 'vector-unfold'.

Depending on what guarantees we want to add about the number of times we call the callback, we can make 'vector-unfold' restart-safe using dynamic-wind. So we would need a fast implementation of dynamic-wind, but this sounds not too far-fetched when we talk about code using call/cc.

If we want to forbid that 'vector-unfold' can be restarted, it should be specified. And it should be guarded against using continuation barriers. In fact, using the language of continuation barriers we can actually write down such a specification of vector-unfold.