[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the discussion so far
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
> 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.