<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
I believe compliance trumps everything else and that's how abcl distinguished itself from any other JVM based implementation of CL.<BR>
From this point of view 1b seems the most reasonable.<BR>
There are two types of users:<BR>
- a programmer writing code, and he/she shouldn't be surprise by anything;<BR>
- a client of the programmer, and he/she shouldn't see any difference one way or the other.<BR> <BR>> Date: Sun, 4 Apr 2010 14:38:40 +0200<BR>> From: ehuels@gmail.com<BR>> To: armedbear-devel@common-lisp.net<BR>> Subject: [armedbear-devel] Unicode support vs spec conformance<BR>> <BR>> This started with Douglas Miles remarking that 2 tests in the ansi<BR>> test suite have been failing ever since we increased CHAR-CODE-LIMIT<BR>> to #x10000.That change was associated with our intended support for<BR>> Unicode.<BR>> <BR>> As it turns out, Unicode has defined characters which conflict with a<BR>> requirement from the CLHS: CLHS requires that characters be defined in<BR>> exact pairs, if they have 'case'. This means that the functions<BR>> char-upcase and char-downcase can be used to retrieve the character's<BR>> "other case" equivalent.<BR>> <BR>> However, in Unicode there are characters which don't have that<BR>> property: for example LATIN SMALL LETTER DOTLESS I maps to the LATIN<BR>> CAPITAL LETTER I, just as the LATIN SMALL LETTER I. Obviously, the<BR>> capital can't map back to both. See here the issue with CLHS<BR>> compliance emerge.<BR>> <BR>> Three possible solutions have come up:<BR>> <BR>> 1a. Be CLHS compliant, but not Unicode<BR>> 1b. Same as (1a), but provide specific Unicode up/down casing functions<BR>> 2. Be Unicode compliant and not CLHS.<BR>> <BR>> SBCL (and from Sam Steingold's remark CLISP too) chooses 1a: I haven't<BR>> found a function to do Unicode up/down casing; it defines the<BR>> uppercase of the dotless i to be itself (caseless). This solution<BR>> results in CLHS compliance, but in my opinion, isn't the solution with<BR>> the least surprise: if you decide you want to upcase a string -<BR>> without in-depth awareness of the issue - you're suddenly faced with a<BR>> string which is upcased, except for a number of characters.<BR>> <BR>> I would propose we - documentedly - diverge from the CLHS on this<BR>> issue: we follow Unicode and the upper case version of the dotless i<BR>> is just the capital i. From a user perspective, this seems like the<BR>> solution of least surprise: I would expect people who use characters<BR>> which can't be round-tripped to understand about that.<BR>> <BR>> Sam suggests there's an issue with symbol i/o. He's probably referring<BR>> to *readtable-case* and *print-case*. My reasoning here too is that<BR>> people using characters like these in their symbols would expect to be<BR>> familiar with both the casing behaviour of the Common Lisp<BR>> reader/printer and the behaviour of their letters in such<BR>> circumstances: if a string were uppercased in a certain way, wouldn't<BR>> it be extremely weird if your symbols wouldn't too - given that your<BR>> Common Lisp claims Unicode support?<BR>> <BR>> <BR>> So, my proposal here is to diverge. What are your opinions?<BR>> <BR>> <BR>> Bye,<BR>> <BR>> <BR>> Erik.<BR>> <BR>> _______________________________________________<BR>> armedbear-devel mailing list<BR>> armedbear-devel@common-lisp.net<BR>> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel<BR> <br /><hr />Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. <a href='http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1' target='_new'>Learn more.</a></body>
</html>