At Mon, 11 Jul 2005 19:14:07 -0700 (PDT), bear wrote:
> First, I feel that SRFI's are not the proper forum for pre-publishing
> R6RS material.  But this is a matter of taste, and if people disagree
> I'll shut up about it.

It's an expedient solution. The editors need a way to offer drafts and
collect feedback, and the SRFI process has all the relevant machinery
in place. In my view, it's a bit of a hack, but not an abusive one.

> Second, I see no point in limiting the representation of unicode
> characters to 2, 4, or 8 hexadecimal digits.

The reason is to match existing string syntaxes, as taken up an another
thread.

> and since a trailing delimiter is
> required in the new syntax

FWIW, I still don't understand where this comes from (but I'm answering
in batch mode, so I haven't given anyone time to reply to eralier
messages).

> Third, I think that char-upcase, char-downcase, string-upcase,
> and string-downcase should be added to the list of functions that
> "may not produce the results an end-user would consider sensible
> with a particular locale," mainly to clarify what the document
> elsewhere says; that they implement the case mappings from
> UnicodeData.txt, rather than locale-dependent case-mappings.

There is no `string-upcase' and `string-downcase' (should we add
them?), but I agree about the warning for the character operations,
and I'll add that to the next draft.

> Fifth, I think you need to add to the general set of character
> predicates defined by SRFI-14 one additional predicate: char-unused?
> which returns true for characters which are inside the valid range
> but which are not actually mapped to any character in Unicode.

I'm not inherently opposed to adding predicates like this, but the
current set of predicates are based on SRFI-14 so that we don't have to
innovate in any way. The SRFI-14 predicates connect to R5RS and satisfy
certain parser needs (such as the definition of whitespace), which is
why we use it.

Many of us think that there are a lot of predicates related to the
Unicode specification that would be useful, but that are not in
SRFI-14. Should these be in the standard, or should they in a separate
library?

Matthew