Hello. I was working with continuations when I realized that if you use join (this [continuation V])@delInput@verticalEllipsis@addInput
, the program reinserts the caller into the returned script. Why is this the case?
Thank you!
Hello. I was working with continuations when I realized that if you use join (this [continuation V])@delInput@verticalEllipsis@addInput
, the program reinserts the caller into the returned script. Why is this the case?
Thank you!
Yeah, THIS CONTINUATION is different from call/cc in that the "this" whose continuation it reports is the THIS CONTINUATION block itself, rather than its caller. I wrote this:
Thank you, but what I meant was that the continuation that is reported is not actually equal to the displayed script. It is hiding the original caller within the continuation, which can only be made visible if you join the continuation. Because of how this works, the following script reports true. (I understand that it wouldn't work if there were multiple frames, but this is just to demonstrate my issue.)
Here's another example:
These (current values, not evaluations) should not be equal. There is no benefit in hiding part of the script from the user.
you might be misunderstanding - or reading way too much into - continuations. There is a Continuations library, it demonstrates how to use this feature, please just use that!
Thank you, but I understand how this [continuation V]
works in Snap!. I realize that I made a mistake with how () = ()@delInput@verticalEllipsis@addInput
works; those two scripts would be equal regardless because of how Snap! handles the equality of scripts. But back to the original question, why does joining (or splitting) the continuation in my scenario reintroduce continuation::reporter control
? Theoretically, joining the continuation should not add anything back into it.
Well, yes, it does...but that's not what I'm saying.
What?
uhh... that's not what it does.
anayway, @blockpointstudios you can always shift-click the snap logo to enter dev mode and the old continuation blocks are still there and are usable.
what?
Thank you, but my issue is also present in those blocks. I believe it's related to how Snap! gets the continuation, not just the reporter.
oh, ok. I will do some testing.
Sigh. Please don't conflate syntax with semantics.
TL;DR: A continuation is a reference to a point of evaluation. Your "continuation" reporter is only hidden in the display of the continuation object, this is to let you know that you can call that continuation and pass a parameter in lieu of the reporter. Syntax operations generate a separate, context-free copy of the blocks, including the hidden one.
Long version:
A continuation is a special kind of function that you can call. It is special, because similar to a closure it captures certain state of the context function it has been created in. The continuation of a reporter is the the input slot it's embedded in, and after the input slot it's the other input slots to the right of the current one, then the block which those input slots belong to, and then the next command block after that block, and so on. Because the continuation is the input slot we're visualizing the continuation as a ring (an anonymous function) around the parent script with the input slot (= "continuation") left blank, so it becomes an implicit input of the ring, i.e. you can call it with a parameter in lieu of the reporter whose continuation you capture. That's a visualization, in other words, we show you something that we hope you recognize, in this case a ring with an empty input slot, and we expect you to then know how to use it (call it with an input that gets mapped to the empty slot). But it's still a visualization, and abstraction, because in reality the whole continuation would be a very, very, complicated and often extremely long and funny looking script (just think about what it would look like to capture a continuation inside a bunch of - nested - loops). As with closures there is more to the object than those blocks we're showing you, state that isn't visualized (and there is always debate whether more state should be visualized). When you join a ring, what exactly do you expect? joining - like splitting - rings operates on the syntax of a ring, and strips away all semantic "überbau", including the visualization of the empty-slot-means-implicit-parameter mechanism. So what you then get is the parent script including all its components. And the reason you're getting the reporter is that the continuation doesn't actually produce a new function but captures an entry point to a stackframe in the evaluator. It's not a regular function (and you can't persist it in the project), but a reference. As such it cannot "strip" stuff away, only hide it in the visualization. When you turn such and object into syntax you get a new ring whose blocks are no longer references but actual, hard, code. And you also get the hidden parts.
I'm not very excited about this whole discussion. Every time someone on this forum uses metaprogramming a mind-blossom withers and a baby function starves to death. Like I pointed out above, you might be misunderstanding - or reading way too much into - continuations. There is a Continuations library, it demonstrates how to use this feature, please just use that!
12 posts were split to a new topic: Metadiscussion about discussion of Snap! development
In my opinion, the continuation should be represented as the reference (which is how it currently works) with an ellipsis at the bottom. Similar to variadic inputs, you could join it with a list containing the number of inputs and arguments to see more of the script. This joined script would no longer have the ellipsis.
I'm really happy with Snap!'s continuations, though. Snap! actually introduced me to them, so I'm grateful!
I've moved the comments that aren't specifically about continuations to a new (closed) topic.