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
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
