[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mixing characters and bytes



Michael Sperber wrote:
> Per Bothner <per@xxxxxxxxxxx> writes:
>
>
>>Note that neither use-case is supported by SRFI-68 unless
>>you stick to UTF-8 or go down into the stream level.
>
>
> The operative word is "stream level" here.  You've argued throughout
> that its usefulness is questionable, but when its usefulness becomes
> apparent, you seem reluctant to use it.

A couple of reasons:
* Performace:  Using streams is expensive - at the very least it puts
a lot of pressure on the garbage collector.  A program that uses
imperative ports should not have to use streams just because it
wants to use a non-utf-8 encoding.
* Complexity:  Having to deal with a very different abstraction
just because I want to use a non-utf-8 encoding complicates my
program and my mental model.
* Switching encodings: You can't switch encodings without switching
ports.

To use other encodings you have to use streams.  To mix encodings or
non-utf-8 text and binary you have to use streams exclusively.  People
should use streams if they want to use the stream (functional) model,
but I don't think requiring people to use streams just because they're
not using utf-8 will fly.

>>Second, some ports are text-only, in the sense that they cannot
>>meaningfully support byte operations.  This includes the string ports
>>specified by SRFI 6.
>
> The string ports specified in SRFI 6 can support byte operations
> perfectly meaningfully.  I believe SRFI 68 contains a variation of it.

I guess so, by essentially converting the string to a blob and
vice versa.  I.e. a stream of characters becomes a stream of
the utf-8 encoding of the characters.  That makes string ports
slightly trickier to implemented but probably not much so.
Ok, I'll buy that.
--
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/