[r6rs-discuss] Re: [Formal] formal comment (ports, characters, strings, Unicode)
I am posting this as an individual member of the Scheme
community. I am not speaking for the R6RS editors, and
this message should not be confused with the editors'
eventual formal response.
Thomas Lord wrote:
> I don't think so. Aren't you saying that you would want
> CHAR->INTEGER to be unable to distinguish #\A from
> a hypothetical, permitted-not-required, #\M-H-A? That
> would leave CHAR->INTEGER total over CHAR and,
> in the presence of those extensions, many-to-one.
Sorry. I *was* saying that, but I was disagreeing with
the conclusions you drew from that. In particular:
> Characters are objects that represent Unicode scalar values [...].
> [....]
> Given a character, char->integer returns its Unicode scalar value as
> an exact integer.
> [....]
> These procedures impose a total ordering on the set of characters
> according to their Unicode scalar values.
>
> All three but especially the last statement are particularly damning.
> A total ordering according to scalar values clearly implies that the
> CHAR type contains no more values than there are scalar value
> integers.
Whether a binary relation is a total ordering depends upon
some notion of equality. If you take char=? (or eqv?) to
be that notion of equality, then char<=? does indeed define
a total ordering on the set of characters.
If you take klepto:char=? (or eq?) to be the notion of
equality, then char<=? may not define a total ordering on
the set of characters. So what?
One last example shows why it is unreasonable to interpret
the language of the draft R6RS to mean that char<=? defines
a total ordering with respect to all possible equivalence
predicates:
(define (klepto:char-equiv? c1 c2)
(let ((i1 (char->integer c1))
(i2 (char->integer c2)))
(or (and (< i1 256) (< i2 256))
(and (>= i1 256) (>= i2 256)))))
That is an equivalence predicate, and it is definable in
R5.92 Scheme, but char<=? does not define a total ordering
with respect to that predicate.
Will
Received on Tue Mar 20 2007 - 15:16:53 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:01 UTC