[r6rs-discuss] Unicode issues

From: Thomas Lord <lord>
Date: Tue, 28 Aug 2007 17:41:44 -0700

John Cowan wrote:
>
> That is to say, 1,112,064 character objects that are distinguishable
> by char= (and a fortiori by eql? [sic. "eqv?"]). There is nothing to prevent an
> implementer from introducing more character objects distinguishable
> by finer-grained predicates.
What you are boasting about is simply that EQ? is permitted to
not always return #t for for EQV? characters -- a permission that
undoubtedly originates in the desire to permit boxed character values.

There are 1,112,064 character objects that are distinguishable
by char= and therefore there are only that number that can be
distinguished by:

    eqv?
    equal?
    string=?
    eqv-based hash functions


And, while an implementor can support a greater number of values
that return #t from CHAR?, if they do so, then

    char->integer is no longer the inverse of integer->char

And, hey, here's a fun one: if an implementor adds TWO non-unicode
values for which CHAR? returns #t then:

    sorting procedures that key on character or string values are
non-deterministic
      even if the input contains only unique keys


So, once again, the only way to add new characters to R6 is to not
use the core. You might -- MIGHT -- still be able to use the native
CHAR? procedure. That's about all you're saying.






>
>> It is generally true that, given only a pure R6 implementation,
>> one could write sufficient libraries that, at least semantically (forget
>> performance) one never needs to use *any* of the core types or
>> procedures of R6 directly. One might wonder why we should then have
>> the core types at all....
>>
>
> Because they are useful in many, though not all, circumstances,
> and because it is therefore worthwhile standardizing their names and
> the names of their associated procedures. (Lists are an exception;
> the language mandates that procedures with rest arguments receive
> lists-as-we-know-them. Syntax-case also intertwingles the R6 core types
> with program generation in a way that syntax-rules did not.)
>
>


I thought "useful in many, though not all, circumstances" was a
good rationale for a library, not a core language feature.

Didn't you?

That isn't to say that core features must be "useful in all
cirumstances" but only that "useful in many" is perhaps necessary
but certainly not sufficient for core features.


-t
Received on Tue Aug 28 2007 - 20:41:44 UTC