[Ecls-list] ongoing testing

Brian Spilsbury brian.spilsbury at gmail.com
Wed May 31 01:03:18 UTC 2006


The main disadvantage of this approach is that it doesn't provide the
abstractions for the streams to use in dealing with the outside world.

Anything which talks to the outside world is going to need to do the
following things.

a) translate lisp objects into sequences of octets.
b) write octets out in some mysterious fashion.

and/or

c) read octets in, in some mysterious fashion
d) translate octets into lisp objects.

The translation of lisp objects to and from octet sequences is
implementable portably.

The mysterious system level i/o isn't.

In general the mysterious system level i/o is going to require
buffering in order to accomodate the difference between how lisp
expects to do i/o and how the system expects to do it.

Consider the difference between a file read and a socket read in unix.

The mysterious i/o level also needs to interact with other mysterious
systems, such as your scheduler.

As an additional benefit, once you've provided a buffered octet
sequence interface to the outside world, you can easily provide
routines which can inspect the sequence afterward decide on how much
to consume, which removes the need for mini-buffers (since you don't
consume sequences which don't form whole characters).

Also, it removes the need for the stream to know what kind of device
it is talking to and implement whatever buffering would be efficient
to talk to it.

Regards,
Brian.




More information about the ecl-devel mailing list