[usocket-devel] Portably supporting :external-format

[Erik Huelsmann]

On 10/23/06, nick thomas <jesuswaffle at gmail.com> wrote:
> On 10/22/06, Erik Huelsmann <ehuels at gmail.com> wrote:
> > Looking at ABCL and flexi-streams though, I do see a problem: ABCL
> > doesn't have a generic function close, but defines STREAM-CLOSE
> > instead... At least flexi-streams 0.5.10 seems to depend on close,
> > open-stream-p and maybe others too, to be generic functions, not just
> > defuns...
> >
> > Well, ABCL isn't in wide use anyway and not going very fast
> > development, but, well, I could ask around with the developers what to
> > expect there. It would indeed be too bad not to be able to support
> > :external-format there, but that's an option too (just ignore the
> > external-format in case of ABCL). We need to make sure to document
> > that though.
> >
> That sounds good to me.

>
> Anyway, feel free to ignore me; your way would work fine, as well. I'm
> just throwing out alternatives here.
>
Oh! No! I'm not ignoring you! Having these discussions with myself is
a lot harder than having them with you ;-) I do have my own opinions,
but talking about pros and cons is a lot better than hitting a wall.
You're really helping usocket forward.

> One minor concern, though: does it make sense to add a whole new
> mandatory dependency (two, in fact) for a relatively obscure feature
> like this?

I think that's funny: :external-format should have become a major
issue for all lisp implementations by now. i18n is really a 'must' for
 any self-respecting application these days. So, any platform worth
developing on should support it.

> Now, I realize I'm backpedaling here, but how about we
> require the user, if they want to use flexi-streams, to just create
> one themselves from the raw streams that we return?

Well, that does simplify matters: if we do that, we only need to
support :element-type to make sure people can create the binary
streams which flexi-streams needs for its input.

> This is a trade-off: it makes things easier for people who don't need
> :external-format or bivalent streams, but it makes things harder for
> people who do. It would also mean that the :external-format flag to
> OPEN-STREAM would remain useless, but, in trivial-sockets itself, it
> only works under CLISP, anyway.

I do like Douglas's idea too: those implementations which do not
support external-format or bivalent streams, will require
flexi-streams. Implementations which *do* support that can use their
internal system.

However that would loose portable external format specifications. It
should be quite trivial to write a mapping from a general spec to
implementation defined ones though.

The other thing we will probably loose is bivalence. On IRC I was told
SBCL will allow stream-read-byte/read-byte on character streams,
effectively making them bivalent, but I'm not sure for any of the
other implementations. There is (in contrast with external-format) no
(setf element-type) method in the standard, so this behaviour will be
implementation specific...

Maybe we can find out by creating a simple test-case to run on all
supported platforms and see if each platform effectively provides
bivalent streams?

bye,

Erik.

PS: I created a generic function in ABCL and it took a measurable
amount of time on my P4-3Ghz 1GB RAM, so I indeed think the ABCL
developers are right: ABCL is dead slow.