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 <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
