Re: Wide strings

[Ludovic Courtès]

Hello!

Neil Jerram <address@hidden> writes:

> But what about the other possible debate, about the API?  Are you
> thinking that we should accept R6RS's choice?

No, I think we have SRFI-1[34] to start with, both of which are well
defined in the context of Unicode.

> (I really haven't read up on all this enough - however when reading
> Tom Lord's analysis just now, I was thinking "why not just specify
> that things like char-upcase don't work in the difficult cases", and
> it seems to me that this is what R6RS chose to do.  So at first glance
> the R6RS API looks OK to me.

Regarding `ß' (German eszet), which is one of the "difficult cases"
mentioned by Tom Lord, SRFI-13 reads:

  Some characters case-map to more than one character.  For example, the
  Latin-1 German eszet character upper-cases to "SS."

    * This means that the R5RS function char-upcase is not well-defined,
      since it is defined to produce a (single) character result.

    * It means that an in-place string-upcase! procedure cannot be
      reliably defined, since the original string may not be long enough
      to contain the result -- an N-character string might upcase to a
      2N-character result.

    * It means that case-insensitive string-matching or searching is
      quite tricky. For example, an n-character string s might match a
      2N-character string s'.

And then:

  SRFI 13 makes no attempt to deal with these issues; it uses a simple
  1-1 locale- and context-independent case-mapping

I think it's reasonable to stick to this approach at first, at least.
Locale-dependent case folding is part of `(ice-9 i18n)' anyway.

Thanks,
Ludo'.