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

Re: Mixing characters and bytes

This page is part of the web mail archives of SRFI 56 from before July 7th, 2015. The new archives for SRFI 56 contain all messages, not just those from before July 7th, 2015.

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

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/