Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
[Was: Batteries-included SBCL]
I'd argue that a better SERVE-EVENTS would be a real event loop, like
that of IOLib.
I'd even argue that SBCL should be using a copy of IOLib for its IO
subsystem, renaming the package into SB-IOLIB after compilation.
Similarly for BABEL, etc.
As for the fact that event-loops are much better used with
continuations -- well, lack of first-class continuations is the bane
of CL. But didn't pkhuong demonstrate that you could reify
continuations? If someone hates CPS, even when generated by macros, as
too inefficient, yet want a better interface to asynchronous I/O than
the event loop, the onus is on him to provide a nicer interface to
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Life is like an onion: you peel off layer after layer,
then you find there is nothing in it.
2009/12/18 Faré <fahree@...>:
> [Was: Batteries-included SBCL]
> I'd argue that a better SERVE-EVENTS would be a real event loop, like
> that of IOLib.
There is widespread agreement here. Everyone I talked with about this
at SBCL10 preferred tools to write their own even loop to having a
magical but subtly broken one like SERVE-EVENT.
> I'd even argue that SBCL should be using a copy of IOLib for its IO
> subsystem, renaming the package into SB-IOLIB after compilation.
> Similarly for BABEL, etc.
Does IOLib does with Windows? Does is use CLOS? For our own IO
subsystem we need something that hides the differences between Windows
and POSIX and doesn't use CLOS.
What I'm saying is that I don't think anyone particularly wants to
maintain more software than they have to -- but replacing bits and
parts of SBCL with external libraries libraries is not quite as simple
as one could hope.
With these caveats in mind, I do think that *if* the maintainer of
library X agrees to play nice with us, there are cases where this
might be very well worth looking into. Playing nice mostly means
giving use enough rope for bootstrapping and caring about Windows at
least as much as we do. (Obviously we aren't the shining example of
Windows compatibility, but most days we do try to make things better
there instead of worse...)