[racket-dev] Coroutines (mzlib/thread)

In this particular case, I would prefer this code not to change, as it
the heart of a subtle and important part of DrRacket's useability (the
syntax colorer). If there are concrete issues with it beyond the
desire for a cleaner interface, that's great and I'd love to see
performance or correctness fixes. If there is just a desire for
generally better code, I would prefer that you do something that
doesn't really touch this code (perhaps by making a layer around it
that, when it gets suitable arguments calls into this code and
otherwise calls into new code but leaves the old interface around for
the framework).

Robby

On Sat, Jul 21, 2012 at 1:41 PM, Asumu Takikawa <asumu at ccs.neu.edu> wrote:
> On 2012-07-20 21:48:38 -0400, Matthias Felleisen wrote:
>> We can build it for real. Both interfaces have separate uses and
>> should be kept separate. -- Matthias
>
> My first thought was that these could be provided by the same interface,
> but let me see if I understand what you're saying.
>
> The issue with providing both options, is that if you provide an `yield`
> operator to implicit co-routines, you take away the ability to place
> all control of yielding from the controller.
>
> So couldn't we provide a version of `coroutine-run` that takes a #:yield
> keyword that enables/disables explicit yielding? If #:yield is off, then
> the `yield` procedure provided to the coroutine would be a no-op. Only
> the implicit yield condition would trigger a context switch.
>
> Otherwise, the procedure would yield and run some default scheduler.
>
> Cheers,
> Asumu
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev