On Sat, 31 Oct 2020 03:25:32 -0700 (PDT),
"jackh...@gmail.com"
<jackhfi...@gmail.com> wrote:
>Wow, these are a lot of great responses. First of all, *awesome* job Ryan.
>That implementation is exactly what I needed to figure out. I'm definitely
>starting there first.
>
>> Are you looking for `let/ec`?
>
>I'd forgotten about that one. That has the *syntax* I want. However my
>issue with continuation-based approaches isn't the syntax, or even the
>performance. It's the semantics. What if someone writes code like this?
>
>(guarded-block
> (define x (random 10))
> (thread
> (lambda ()
> (guard (even? x) else #false)
> ...)))
>
>If I implemented guarded-block in terms of let/ec, then what does this code
>even *do*? I honestly don't know. It would probably run without error and
>do... something.
(let/ec return
(thread
(lambda ()
(return -1)
42)))
throws an error: "continuation application: attempt to jump into an
escape continuation"
There is a continuation barrier between the threads.
However, let/cc works: e.g.,
(let/cc return
(thread
(lambda ()
(return -1)
42)))
returns -1.
>I am extremely sure that regardless of what it did, it
>would be confusing and it wouldn't solve any problem I had.
I am sure it would solve *some* problems.
>I just flat out don't want to allow this or any related nonsense,
>such as:
>
>; Aliasing
>(define return guard)
>
>; Higher-order usage
>(map guard (some-list ...))
>
>; Capturing via closure
>(guarded-block
> (define (check-foo x) (guard (foo? x) else #false))
> (check-foo ...)
> ...)
>
>; Capturing via mutation
>(set! previous-guard guard)
>
>; Oh great, now I have to think about even more continuation jumps
>(dynamic-wind
> (lambda () (guard ...))
> (lambda () ...)
> (lambda () ...))
>
>There might be valid use cases for some of these, but I certainly don't
>understand those use cases well enough to commit to a semantics for them.
It always is safe to jump upwards OUT of a lower level computation.
The sticky issues [and mental gyrations] with continuations all have
to do with jumping downwards or sideways.
I'm not sure what problems you might have with continuation barriers:
the example of the thread shows that (upward-only) "escape"
continuations don't work across threads ... but "full" continations do
work, and would still work even if the threads were siblings rather
than in a parent/child relationship.
The issue for your purpose would be making sure the continuation is
called from a position that is guaranteed to terminate the errant
thread: you might need to recognize a thread as a special case, wrap
it and (like an exception) catch/rethrow the continuation.
Or, if you don't care about sibling threads, just use exceptions which
always can be thrown upward out of child threads.
George
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/2r6upftjom3aipt0g32nkcmikdc37je2t6%404ax.com.
