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 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/