John Cowan wrote:
Thomas Lord scripsit:
Example: I've used the CHAR type in a traditional lisp way: to
represent typed characters with "bucky bits" like
META-ALT-SUPER-X. I understand others have as well
and do you agree permitting at least /that/ would be a reasonable
compromise? If that example should be permitted that gives us at least
a loosening of the range restrictions.
If you want those, then introduce the type BUCKY-CHAR, a supertype of
CHAR. Why not?
For example, what is a STRING?
That way CHAR remains portable and you can work in
BUCKY-CHARs and, if needed, BUCKY-STRINGS.
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?
Example: Scheme has been used quite a few times, successfully,
in embedded systems (such as controlling small robots). Such
applications often need a small footprint and don't need, for
example, large Unicode property tables. If that's permitted, that
gives us a shrinking of the mandatory character set.
Fortunately, the property tables are needed only if the program
imports (r6rs unicode) -- the base library doesn't have any
procedures depending on Unicode properties.
Then that would be another regression from R5 in which the
standard character-case procedures were useful for programs
which (for example) use them to manipulate their own source.
-t
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
