[r6rs-discuss] Re: [Formal] formal comment (ports, characters, strings, Unicode)
William D Clinger wrote:
> 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'd given some thought to that. You could describe it by saying
>> that CHAR->INTEGER *must* be total over CHAR and *may* be
>> a many-to-one function while INTEGER->CHAR *must* be
>> non-divergent only for numeric scalar values and, over that
>> domain, *must* be an injection into CHAR.
>>
>
> I did not describe what you just described. I described
> an alternative in which "an implementation could add bucky
> bits to characters while making those bits invisible to
> all of the standard operations on characters and strings."
> What you are describing would make those bits visible to
> the standard operations.
>
???
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.
If bucky-bits are to be "invisible to standard operations" then
I gather you'd have INTEGER->CHAR remain restricted
to scalar value integers, making it an injection into the
extended CHAR type.
>
>> The language
>> of 5.92 seems to me to explicitly forbid this interpretation but
>> you have brought into consideration so let's see where it goes.
>>
>
> I did not propose anything that would violate the language
> of the 5.92 draft.
>
>
Perhaps you could unpack things a bit, then. 5.92 seems to me to
prohibit implementations which have more characters than there are
Unicode scalar values:
/ 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.
>
>
>> Finally, I think there is a debate implicit in this explicit debate.
>> It seems to me that you and Cowan would like Scheme programs
>> to be type-safe in an unprecedented way that goes beyond the
>> type safety goals of the report:
>>
>
> I appreciate the joke.
>
>
It's funny, yes, but not simply a joke. Perhaps it failed but I'm
trying to figure out a concise principle on which we can agree that
transcends but also resolves the debate.
-t
> Will
>
>
Received on Tue Mar 20 2007 - 14:28:02 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:01 UTC