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 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