Concurrency as Continuations as Send/Recv

[hkr-droid]

So scheme programmers love their call/cc, and continuations are often mentioned in concurrency semantics as ways of staging computation until later, reentering different points in a program, etc. What if we just directly translated scheme's cal-with-current-continuation into erlang's send/recv?

🤷

[zsisco]

I think you're on to something there. Especially since Core Erlang has direct commands called "receive" and such. Seems like it follow naturally.

[gavrilovmiroslav]

Sorry for just barging in. This might be useful: look for the "Erlang for Functional Programmers" books (might be something like "Erlang & Elixir for Functional Programmers"?) by W. Loder I think. I'll check out whether I'm right as soon as I get to a desktop, but anyway: there's an example of implementing call/cc by using send/receive. This isn't at all new, however, as the send/receive model has been and continues to be used to both emulate, and support, other models of both concurrency and (through simulation) other paradigms.

The "what if we translate call/cc into send/receive" question fits one of those categories. Could you elaborate on the "why" of this? I find that Scheme programmers love call/cc for the same reason for which Haskell programmers love their monads, and Erlang their actor model, and CPP their RAII and so on: they give them direct guarantees and indirect resource handling and management for the domain of problems they care about. I think at least a few sentences about the problem you're approaching, taking these domain into account, could benefit understanding.

Then again, I'm not really there, and I may be a figment of your imagination, so don't feel obliged to answer this!

[hkr-droid]

I am glad you barged in, that book sounds perfect.

For context, this is our class project for 263 Runtime Systems. We decided we'd translate a subset of scheme to the erlang vm. The main reason we'd do that is to see how we can express concurrency features in a lambda calculus (unsure which flavor at this point). I think we're both still just trying to build a foundation for concurrency/parallelism stuff though, so any advice you have definitely goes a long way.