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 <as...@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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
