On Tue, Jul 30, 2013 at 5:28 AM, Ian P. Cooke <i...@informatic.io> wrote:
> I agree continuations are not a required language feature for a minimal > language although I believe the ability to implement them in a library > without runtime modification should be a requirement. If tasks are part of > the language/runtime (e.g. Rust, Go) and allow as much control then I think > I would not be reaching for continuations. > If by continuations you mean support for something like CPS, I see no problem. If by continuations you mean *reentrant* continuations in the style of scheme CALL/CC, then I would say that a language should work very hard to make them impossible. Viewed as a control mechanism, continuations do incredible damage to the control flow structure of a program, and they make linking with other languages all but impossible. The relevant tests are: 1. Can the captured continuation be invoked more than once? [answer must be no] 2. Can the captured continuation outlive the scope of capture? [answer must be no] Strictly speaking, [2] is a bit too strong. What's actually necessary is that the continuation dies before any of the bindings in its closure dies. Basically, continuations must obey stack lifespans. Note that if these two restrictions hold, continuations are merely a variant of exceptions. Continuations introduce causality bifurcation into the programming model. That's even harder to think about than concurrency! shap
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
