[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Response to SRFI 75.

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.

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

> 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

> 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