On 7/6/07, Brian Mastenbrook <brian@...> wrote:
> Thomas F. Burdick wrote:
> > And then there's the stuff I wouldn't really expect to ever get
> > merged, like DWIMy (or DW A Western European M) support for 8-bit
> > characters in the unicode build; porting serve-event to the Tcl event
> > loop; continuations; and so on.
> Continuations? Do tell.
I put a CPS transformer in front of the compiler, played tricks with
packages to make the CLwC look for the most part like SBCL, from
within the CLwC dialect, had a calling convention for "simple" CL
functions, and was able to compile significant parts of the SBCL
source code to get a lot of the higher-order functions available. I
didn't even attempt to touch PCL. The result was fun to play with,
but kind of a disaster as a Lisp dialect; you can see implementation
details everywhere when you try to return a second time through a
continuation, e.g., the fact that mapcar is implemented using
destructive operations, every unwind-protect, etc. And that's not
even considering those cases where a lot of Schemes just give up (like
re-returning from a macro-expansion function, which *should* IMO
redefine the appropriate function, but raised an error in my hack, and
apparently can crash some schemes).
> Regarding serve-event, one of my never-gonna-get-to-it todo items
> involves adding enough hooks that a user can rip out select() and
> replace it with a function of their own, which is useful for integration
> with many different external libraries that all expect to be in charge
> of the event loop.
Yeah, this is the right way to do it, and Somebody ought to do it,
probably around the time that Somebody looks really hard at
serve-event and threads. Losing support for select() in favor of the
Tcl event loop or /dev/poll can be a 100% win as a local change, but
would of course not be merged. Although I guess something GP enough
like /dev/poll, kqueues, and friends could maybe go in dependent on
appropriate features, failing a good swappable serve-event.