SBCL Internals The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed

The motivation for replacing fd-streams at this time:

1. we need to do streams things for Unicode
2. serve-event has reentrancy problems and doesn't work when multiple threads are running
3. it's more than passing weird

Comment from cliini on translation layers (applies to document v3) at http://meme.b9.com/cview.html?utime=3305194150&channel=lisp&start=3305194000&end=3305195000#utime_requested

Are you considering something other than Franz simple-streams??? (And if so, why?) Disclaimer: I am not a fu-streams expert (or even a streams expert), so take the following with a grain of salt. I think the conclusion on #lisp was that simple-streams attempted to cope with some internal design decisions of Allegro (i.e. backwards compatibility was a priority) and therefore was not as general/flexible as it could be. Corrections welcome. --Nathan Froyd

Simple streams is rather octet centric: it doesn't even have a way to define string stream with its own primitives so it is just bolted on as a special case. --Gabor Melis

Ideally, fu-streams are composable and the composition can be compiled/optimized for performance. Investigating how SERIES manages to do something similar may be inspirational for the reader. Implementing sealing for CLOS can also be advantageous.

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively