Email list hosting service & mailing list manager

the discussion so far Matthew Flatt (16 Jul 2005 12:41 UTC)
(missing)
(missing)
(missing)
Re: the discussion so far bear (20 Jul 2005 02:45 UTC)
Re: the discussion so far John.Cowan (20 Jul 2005 03:56 UTC)
(missing)
Re: the discussion so far Alex Shinn (20 Jul 2005 02:50 UTC)
Re: the discussion so far Thomas Bushnell BSG (20 Jul 2005 02:56 UTC)
Re: the discussion so far Alex Shinn (20 Jul 2005 03:15 UTC)
Re: the discussion so far Thomas Bushnell BSG (20 Jul 2005 03:24 UTC)
Re: the discussion so far Alex Shinn (20 Jul 2005 03:38 UTC)
Re: the discussion so far Thomas Bushnell BSG (20 Jul 2005 03:49 UTC)
Re: the discussion so far John.Cowan (20 Jul 2005 04:24 UTC)
Re: the discussion so far Thomas Bushnell BSG (20 Jul 2005 04:27 UTC)
Re: the discussion so far John.Cowan (20 Jul 2005 04:58 UTC)
Re: the discussion so far Thomas Bushnell BSG (20 Jul 2005 05:04 UTC)
Re: the discussion so far Jorgen Schaefer (16 Jul 2005 13:05 UTC)
Re: the discussion so far Matthew Flatt (16 Jul 2005 13:21 UTC)
Re: the discussion so far Jorgen Schaefer (16 Jul 2005 13:58 UTC)
Re: the discussion so far Thomas Bushnell BSG (17 Jul 2005 02:42 UTC)
Re: the discussion so far Thomas Bushnell BSG (17 Jul 2005 02:57 UTC)
Re: the discussion so far Jorgen Schaefer (17 Jul 2005 03:33 UTC)
Re: the discussion so far bear (16 Jul 2005 18:07 UTC)
Re: the discussion so far John.Cowan (17 Jul 2005 04:49 UTC)
Re: the discussion so far Thomas Bushnell BSG (17 Jul 2005 02:40 UTC)

Re: the discussion so far Thomas Bushnell BSG 20 Jul 2005 02:56 UTC

Alex Shinn <xxxxxx@gmail.com> 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.