[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: about coroutines

From: mibin
Subject: Re: about coroutines
Date: Mon, 10 Dec 2001 21:52:01 +0100

>>>>> "mvo" == Marius Vollmer <address@hidden> writes:

  mvo> Yeees, but.  One also needs to make compromises for practical
  mvo> reasons.  The module system needs support deep in the
  mvo> implementation, for example, and the Scheme reports don't even
  mvo> talk about error handling, something which I consider very
  mvo> important for a practical programming language or system.

  mvo> Continuations in the presence of dynamic-wind can't really be
  mvo> used to implement multi-threading, I'd say.

  mvo> One-shot continuations have been considered for performance
  mvo> reasons, I think.  We would add that they help with
  mvo> conservative GC and stack copying, too.

I have been thinking about commands to explicitly invalidate or
replace a continuation object, but having one-shot continuations seems
a much more elegant solution.

For the record, here is my one-shot version of call/cc (it also makes
my original test code run in finite space).

(let ((already-invoked-error
         (lambda any
           (error "Single shot continuation invoked twice!"))))
    (lambda (thunk)
       (lambda (cont)
         (set! cont (list cont))
         (thunk (lambda (return-value)
                  (let ((a (car cont)))
                    (set-car! cont already-invoked-error)
                    (a return-value))))))))

  mvo> But we should probably better try to rid us from the drawbacks
  mvo> of conservative GC...

This sounds kinda utopian to me (I'd like to be proven wrong, though).

>>>>> "Keith" == Keith Wright <address@hidden> writes:

  RnRS> Programming languages should be designed not by piling feature
  RnRS> on top of feature, but by removing the restrictions that make
  RnRS> additional features appear necessary.

  Keith> We already have throw with catch and lazy-catch for
  Keith> continuations that are used only in restricted situations,
  Keith> and coop-threads seem like coroutines by any other name.  I'm
  Keith> just not happy to see more half done continuations.

Me neither.  Unfortunately stack copying based continuations are too
inefficient, for example to implement threads or even plain
coroutines.  Things would be different if the evaluator was
implemented in a way that made continuations derivable in constant


reply via email to

[Prev in Thread] Current Thread [Next in Thread]