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: > The primary argument in favor of keeping the names as-is is partial > backwards compatibility with R5RS. The problem here is that R5RS is broken. If we are to have fixed standards, when the previous one is actually broken, then we just have to deal with the fact that code which used the broken interface will no be standard. Those implementations that want to provide the old named functions can continue to do so, of course. > Character-level case operations are currently used in programs for > one of two semantic reasons - either ASCII-based parsing or > linguistic case mapping. In the former case, keeping the current > R5RS names means no changes are needed and the program continues to > function properly. In the latter case, the code is fundamentally > broken and needs to be rewritten to use string-level operations > anyway. Unfortunately, in the latter case the code will continue to > work for English-speaking authors so the rewrite is not so likely to > take place. Do we favor backwards compatibility as much as > possible, or do we introduce deliberate incompatibility and force > people not to use broken concepts? Neither. We let Scheme systems decide; some systems will prefer incompatibility and correctness, some systems will prefer backwards compatibility. This is as it should be. In other words, faced with a conundrum, where which choice is right depends on the particular case, we are well advised to standardize neither behavior. > This decision is also affected by the overall naming convention of the > SRFI. If we are to have separate ASCII-based procedures and > Unicode-aware procedures, in general are the R5RS procedures thought of > as ASCII or as Unicode? The Scheme procedures should work on characters. The R5RS char-based case procedures are best dropped. The rest are just fine as they are. > On another note, so far the conversation is neglecting the predicates > CHAR-*CASE?. Since these are defined as Unicode properties of > individual characters it does make sense to keep these as character > level operations. I believe this is correct, but I'm not certain enough to agree conclusively. But it does match me recollection of the situation.