This page is part of the web mail archives of SRFI 75 from before July 7th, 2015. The new archives for SRFI 75 contain all messages, not just those from before July 7th, 2015.
Alex Shinn <alexshinn@xxxxxxxxx> writes: > I'm sorry, perhaps I misunderstood, but I'm still not clear what you're > arguing in favor of. Do you want to leave all existing R5RS character and > string procedures unspecified, optionally introducing new versions with > ascii- or unicode- prefixes? Well, what I'm arguing in favor of is standardizing only things which will not hamper fancy-schmancy "full-Unicode" support (with all the optional little bits that aren't Unicode-proper). I am arguing against the requirement of functions which are being specified to do things which are the Wrong Thing on such systems, both because: The system shouldn't be forced to have a bogus function lying around confusing its users, and Portable code should automagically do the right thing on a fancy-schmancy system. Suppose we made the mistake of saying that all numbers must be comparable by <, with full trichotomy. Or we demanded that multiplication must be commutative. Then we would have messed up. We would have prevented complex numbers or quaternions from being implemented carefully. By contrast, Scheme did this right. Nobody has to support complex numbers or quaternions, but we also don't specify whether multiplication is commutative or whether < is a total order on numbers. I want generically-named procedures to do the correct generic thing on the local system. I want no generically-named procedures mandated by the standard when they cannot be implemented correctly on a fancy/schmancy system. If there is a need or desire for non-generically-named procedures, that's fine. So ascii-upcase (or whatever) is fine. But char-upcase is not, even if you then say "oh, and it breaks if the character isn't ascii." This means we must get rid of the existing case-mapping functions in R5RS. They must go. They are the *problem*. Now if you want, as a system implementor, to continue to implement them, go right ahead. But *please* don't force every Scheme system, include a fancy/schmancy one, to do so! Thomas