[r6rs-discuss] Re: [Formal] formal comment (ports, characters, strings, Unicode)

From: William D Clinger <will>
Date: Tue Mar 20 18:30:40 2007

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:

> If a programmatic equivalence predicate, relative to each particular
> implementation, isn't implied by "the set of characters" then I don't
> know what is.

The phrase refers to the set of characters that is visible
via certain standard procedures. It does not refer to the
potentially larger set of representations for characters
that might be visible to implementation-dependent procedures,
which may operate at a much lower level of abstraction. For
example, an implementation-dependent procedure that returns
the address of a character object might return two different
addresses for two different instances of #\a.

As evidence that the current draft intends to allow such
things, please note that (eq? #\A #\A) may return false
(R5.92RS section 9.6).

If you want to argue that the draft R6RS forbids systems to
provide or to use implementation-dependent procedures that
operate at lower levels of abstraction, then you might as
well stop reading here. Just make your argument, which I
won't bother to read.

If you do *not* want to argue that the draft R6RS forbids
implementation-dependent procedures that operate at lower
levels of abstraction, then you might as well stop reading
here, since your previous line of argument depended upon
that assumption.

> In that case, you can't have the 5.92 definition that insists EQV?
> behaves like CHAR=? and simultaneously have the, let's call it
> "liberal" reading you give the section on the CHAR type.

By "can't", you mean you don't want to let me interpret
the draft R6RS as saying both (1) char=? behaves like eqv?
restricted to characters and (2) low-level procedures
such as eq? are allowed to observe differences that are
invisible to eqv? and char=?. The problem with your "can't"
is that the draft R6RS really does say both things.

Meanwhile, you pull the concept of "programmatic equivalence"
out of thin air and use it as foundation of your argument.
What you mean, I think, is "observable equivalence", which
is *always* relative to the observables. What is observable
using the standard procedures may be a proper subset of
what is observable using the standard procedures plus some
implementation-dependent procedures. In this case, however,
the standard eq? procedure may already be able to observe
the difference.

> I know,
> you already mentioned the possibility of messing with EQV?
> here, but, really? Is it that you don't want EQV? to be consistent
> with proved programmatic equivalence or that you want to hork
> all existing code that uses EQV? rather than EQUAL? in
> contexts where it is applied to characters? Or what?

As I stated earlier:

Finally, I'd like to note that the current draft R6RS
does not actually preclude bucky bits. An implementation
could add bucky bits to characters while making those
bits invisible to all of the standard operations on
characters and strings. An implementation-dependent
library could make those bits visible. (That would
mess up some programmers' mental model of eqv?, but
their model of eqv? is pretty messed up anyway. The
eq? and eqv? procedures have no special status apart
from constraints that are laid out by the report(s).)

Will
Received on Tue Mar 20 2007 - 18:30:34 UTC