[r6rs-discuss] Re: [Formal] formal comment (ports, characters, strings, Unicode)

From: Thomas Lord <lord>
Date: Mon Mar 19 14:03:25 2007

Per Bothner wrote:
> Thomas Lord wrote:
>> Why can't I write a procedure that, say, reverses a string-like
>> value which can be either a BUCKY-STRING or a STRING
>> and which is a strictly portable procedure using just the core
>> functionality for strings?
>
> Because there is no such thing as "portably reversing a string".

? There certainly is in R5.

> The semantics of doing so depends on what you consider the
> "character units", which depends not only on language but also
> on context.

The context in this subthread is an imagined set of character-like values
that includes the Unicode scalar values central to reflection on
Scheme source, plus other characters that include "bucky bits".


>
> The way to do it is with some kind of matcher/parser that
> gets "the next character", extracts the corresponding sub-string,
> and then concatenates the substrings in reverse order.
>
> I.e. even this artificial (i.e. non-real-world puzzle-only) use-case
> should be solved using string operations, rather than character
> operations.


Given something over 30 years worth of bucky-bit characters
in lisp systems, why do think this is a non-real-world, puzzle-only,
artificial use-case? That's not even getting into the speculative
but quite real-world reasons to permit other extensions to the
CHAR type.

The main point here, overall, is that in 5.92 the CHAR and
STRING types are badly over-constrained and PORT has
been unwisely moved out of the core. I don't entirely
disagree that string-ops are the way to go for many applications.
I agree we don't clearly know what the ideal CHAR and STRING
types are. What I hope you'll agree, at some point, is that 5.92
limits CHAR and STRING more than it ought to or needs to
(and that PORT belongs alongside them in the report).

-t
Received on Mon Mar 19 2007 - 14:12:43 UTC