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 _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
