Keynote: Delimited Continuations, Demystified by Alexis King | Lambda Days 2023
Вставка
- Опубліковано 5 лип 2023
- ✨This talk was recorded at Lambda Days 2023. If you're curious about our upcoming event, check lambdadays.org ✨
Although delimited continuations are not a new idea, they have recently seen renewed interest from several programming language communities as a powerful tool for implementing schedulers and effect systems.
Unfortunately, there is a major remaining obstacle to their adoption, namely that most programmers find them utterly opaque. To help fix that, this talk provides an overview of what delimited continuations are, how they work, and why they’re useful from a perspective accessible to the working programmer.
Let's keep in touch! Follow us on:
Twitter: / lambdadays
LinkedIn: / lambda-days
Facebook: / lambdadays - Наука та технологія
I think this is the first time I've fully grasped delimited continuations. Thanks!
You know its likely to be a good talk when Simon Payton Jones is asking questions
the best way to understand continuations is to learn continuation passing style, you can do continuations in any program that supports higher order functions, the problem is that people is scared away of CPS as something the compiler should do, then they get frustrated because they don't understand what the compiler is doing.
don't say that is boring, say that is a simple mechanism that allows for powerful flow control
44:17 people have CoW-ed memory pages when they fork() since time immemorial... Why not map those memory as CoW instead of copying pessimistically?
That appears to make a lot of sense, but perhaps they almost always get mutated directly after?
59:10 because other programming languages are too deep into an unhealthy relationship with dependency injection, they can no longer conceptualize the beauty of proper one-shot delimited continuation 😅
... so it is just like the do sugar for monads ... just more versatile and normal ...
A lot more, but they also have performance implications that can be very helpful!
Effect handlers, monadic reflection, and delimited continuations have equivalent expressivity (and macro-express each other) when types are not taken into consideration. If type preservation is considered, effect handlers lose type information when translated to delimited continuations or monadic reflections. This is the only difference between them.
This sounds a lot like the handlers in Unison
They are implemented with delimited continuations I think.
Yep, that is exactly the kind of effect system that this is intended for building
very clear explanation of a complex topic, the idea doesn't seem appealing tho. complicates the programmers model of program execution and messes with simple controll flow. hard pass for me.
Edit: Thinking about it a bit more makes me more positive: They are an excellent notation to describe the wack control flow that language features like exceptions or exiting have.
The point is that it is powerful enough to implement many features that are usually language level, such as generators, coroutines and algebraic effects.
@@poscat0x04
I really like this Dijkstra quote: "Our intellectual powers are rather geared to master static relations and our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible."
I don't disagree that they are a very powerful technique, I just think that the sort of twisted evaluation that delimited continuations entail are far far away from its textual representation.
@@blacky7801 Honestly I'm not buying into this handwavy anti-abstraction nonsence, even if it's said from dijkstra (after all he didn't provide any reason behind this judgement). The contemporary philosophy on programming/software engineering is that programming is all about managing complexity, which is done through abstraction.
@@poscat0x04 I don't see where this quote is anti-abstraction at all?
The article this quote is from is his famous "go to statement considered harmful" article in which he argues against the use of goto. He was a proponent of structured programming, a higher level of abstraction compared to the structureless programming that goto allows.
The argument presented in the article is that go to makes tracking the progress of any process impossible. Tracking the progress of a function is of course vital to understanding its behaviour, as its part of the internal state. In a program consisting of only of assignment statements, it is easy to characterize the progress: by a single instruction pointer. In a program consisting of function calls, it is again easy to characterize the progress: by a callstack. Simple and predictable. However, in the case of a program containing goto statements it is impossible to reason about the progress of the process in the general case. Including it in a Language breaks the simple execution model present in structured programming.
Thinking about it this way, adding delimited continuations to a language causes the same breaks to the simple reduction semantics. At any given step in the redduction it is impossible to determine the progress of it, as reduction rules containing delimited continuations can rewrite the past almost at will. There is no understanding the behaviour of a function if the continuation to be reduced can change under you feet at any moment. Delimited continuations are the opposite of managing complexity, they are introducing complexity in reduction where before there was simplicity.
I've seen it argued that "un-delimited" continuations (like in Scheme) are much worse, and that delimited continuations are a better language primitive. You might also be interested in algebraic effect handlers, which as far as I understand is basically statically-typed delimited continuation. See for example the new OCaml effect system, or the Koka research language.