Hacker News new | ask | show | jobs
by naasking 343 days ago
> Because async/await are not values

They are computations that produce values. Computations can be reified as values. What do you think functions and threads are?

As I described above, "delimited continuations" are values that subsume async/await and many other kinds of effects. You can handle async/await like any other value if they were reified as delimited continuations, but this makes the compiler writer's life much more difficult.
1 comments
SkiFire13 342 days ago
> As I described above, "delimited continuations" are values that subsume async/await and many other kinds of effects.

Supporting delimited continuations force some specific ways of performing computations. They are akin to making everything async, which proves my point: you have to make everything of one kind in order to solve the problem.

link
naasking 342 days ago
> They are akin to making everything async, which proves my point: you have to make everything of one kind in order to solve the problem.

You can use ordinary direct style compilation, but all references to stack values simply have to be relative offsets, then a simple implementation of shift/reset is just capturing context and copying stack fragments, which you can do using setjmp/longjmp in C (although there are better ways [1]).

This is not akin to making everything async, nor is everything "of one kind", whatever that means. A delimited continuation is very much its own kind of thing, distinct from other values, and doesn't have to influence the function call/return semantics unless you're targeting a less flexible runtime like the JVM.

[1] https://github.com/koka-lang/libhandle

link
SkiFire13 342 days ago
> but all references to stack values simply have to be relative offsets

Then such references are no longer pointers, and in order to have a generic reference (that can point to both stack memory and heap memory) you have to store additional data (which one of them it points to) and conditionally use the correct one any time you access it. This is a very invasive change to the memory model.

> then a simple implementation of shift/reset is just capturing context and copying stack fragments, which you can do using setjmp/longjmp in C

That sounds like you're just reinventing green threads then, which basically forces everything to be async once you start noticing its issues.

> https://github.com/koka-lang/libhandle

This returns a 404 error for me.

> This is not akin to making everything async, nor is everything "of one kind", whatever that means.

Sure, if everything has to be able to "wait" for the result of a continuation then you're forcing async support on everything.

If instead you implement continuations as some kind of monads that users have to return from their functions then you got function coloring because you can't normally wait for the result of a continuation from a function that does not return a continuation.

link
naasking 342 days ago
> https://github.com/koka-lang/libhandle

Dropped the r somehow:

https://github.com/koka-lang/libhandler

> Sure, if everything has to be able to "wait" for the result of a continuation then you're forcing async support on everything.

If "forcing async support" doesn't mean that code has to change, or any other code in the call chain, then it's just meaningless pedantry.

link