[racket-dev] Coroutines (mzlib/thread)

When I wrote 'interface' I meant two different abstractions, 
separate from each other, and with distinct implementations. 



-- Matthias



On Jul 21, 2012, at 2:52 PM, Robby Findler wrote:

> 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