CLHS: Issue CHAR-NAME-CASE Writeup

#

## Issue CHAR-NAME-CASE Writeup

    Issue:        CHAR-NAME-CASE
    Forum:	      Editorial
    References:   CHAR-NAME (p242), NAME-CHAR (p243), #\ (p353)
    Category:     Clarification
    Edit history: 01-Mar-91, Version 1 by Pitman
    	      08-Apr-91, Version 2 by Pitman
    Status:	      X3J13 passed option X3J13-MAR-91 on a 9-3 vote, March 1991.

    Problem Description:

      In what case is a char name?  Specifically,

      1. Which of (NAME-CHAR "SPACE"), (NAME-CHAR "Space"), (NAME-CHAR "space")
         is a legitimate way to name the Space character?  [CLtL seems to
         make this clear, but then later says things that make one wonder.]

      2. Does (CHAR-NAME #\Space) yield "Space", "SPACE, or "space" ?

      CLtL, p353, says:

          #\name reads in a character object whose name is name
          (actually, whose name is (string-upcase name); therefore the
          syntax is case insensitive).

      This would seem to imply that (CHAR-NAME #\Space) => "SPACE"
      and further that only because of the syntax does lookup of
      #\Space succeed, which would imply that (NAME-CHAR "Space")
      should fail.

      CLtL, p243 (for NAME-CHAR), says:

          If the name is the same as the name of a character object (as
          determined by STRING-EQUAL), that object is returned.

      CLtL, p242 (for CHAR-NAME), says:

          Graphic characters may or may not have names.

      This would seem to `license' an implementation to give names to chars
      like "A" and "$" if they wanted.  But that can't really work in
      general because "A" and "a" if compared by STRING-EQUAL will seem
      the same, when in fact two different characters are almost surely
      implied.

    Proposal (CHAR-NAME-CASE:X3J13-MAR-91):

     Specify that all character names are two or more characters long.

     Specify that CHAR-NAME returns names of characters in the case
     mentioned in the description of CHAR-NAME (i.e., "Tab", "Page",
     "Rubout", "Linefeed", "Return", "Backspace", "Newline", "Space").

    Proposal (CHAR-NAME-CASE:ANY-IN-CAPITALIZE-OUT):

      1. Define that NAME-CHAR is case-sensistive for names one character long,
         but case-insensitive for longer names.

      2. Define that if CHAR-NAME returns a string, that string is either
    	  a long name (a string of length greater than one) in
    	  capitalized (i.e., uppercase initial) format
          OR  a short name (a string one character long) which contains only
    	  one character, which has the same character code as the argument
    	  to CHAR-NAME.

      Test case:

       1. a. (NAME-CHAR "SPACE") => #\Space
          b. (NAME-CHAR "Space") => #\Space
          c. (NAME-CHAR "space") => #\Space
          d. (MEMBER (NAME-CHAR "A") '(NIL #\A)) => true
          e. (MEMBER (NAME-CHAR "a") '(NIL #\a)) => true

       2. a. (EQUAL (CHAR-NAME #\Space) "Space") => true
          b. (MEMBER (CHAR-NAME #\a) '(NIL "a") :test #'EQUAL) => true
          c. (MEMBER (CHAR-NAME #\A) '(NIL "A") :test #'EQUAL) => true

      Rationale:

       A primary purpose of these operators is to support input
       (e.g., the #\ reader macro) and and output (e.g., PRIN1 and
       FORMAT's ~@C) of characters.

       1. It would be confusing for "Space" and "SPACE" to map to different
          characters, and just plain frustrating for one to be valid
          while the other was useless.

       2. It is most useful for this to return a known case so that users
          who care about the presentation are saved from calling STRING-UPCASE,
          STRING-CAPITALIZE, or STRING-DOWNCASE even when the result might
          already come back that way.  The most common thing to do with a name
          is to print it (e.g., when printing a character), so capitalization
          makes the most sense.

    Proposal (CHAR-NAME-CASE:CASE-SENSITIVE):

      1. Define that NAME-CHAR is case-sensitive.

      2. Define that CHAR-NAME returns the names "Space" and "Newline"
         (and "Rubout", "Page", "Tab", "Backspace", "Return", and "Linefeed"
          if they are supported by the implementation) in uppercase initial.

      3. Define that #\ is case-sensitive.

      4. Define that the names "SPACE" and "space" are synonyms for "Space".
         Define that the names "NEWLINE" and "newline" are synonyms for "Newline".
         And likewise for "Rubout", "Page", "Tab", "Backspace", "Return",
         and "Linefeed" if they are supported.

      Test case:

       1. a. (NAME-CHAR "SPACE") => #\Space
          b. (NAME-CHAR "Space") => NIL
          c. (NAME-CHAR "Space") => NIL
          d. (MEMBER (NAME-CHAR "A") '(NIL #\A)) => true
          e. (MEMBER (NAME-CHAR "a") '(NIL #\a)) => true

       2. a. (EQUAL (CHAR-NAME #\Space) "SPACE") => true
          b. (MEMBER (CHAR-NAME #\a) '(NIL "a") :test #'EQUAL) => true
          c. (MEMBER (CHAR-NAME #\A) '(NIL "A") :test #'EQUAL) => true

      Rationale:

       1. This leaves flexibility for other languages or notations
          which have long names for glyphs that make some kind of case.
          e.g.,
    	    (NAME-CHAR "ALPHA")
          might want to be distinguished from
    	    (NAME-CHAR "alpha")
          in Greek, with the former representing an uppercase character
          and the latter representing a lowercase character.

          The choice of uppercase initial means that when printing #\xxx,
          no case conversion is needed.  Saving the time and in some
          implementations the space required to do case conversion.

       2. This assures that (NAME-CHAR (CHAR-NAME x)) => x,
          when (CHAR-NAME x) is not NIL.

       3. This is necessary in order for #\ALPHA and #\alpha to be
          distinguishable.

       4. This keeps compatibility concerns for existing usages of
          #\space, #\SPACE, #\newline, and #\NEWLINE from becoming
          the overwhelming issue.

    Current Practice:

      Symbolics Genera implements ANY-IN-CAPITALIZE-OUT.

    Cost to Implementors:

      Both proposals are probably relatively cheap to implement.

    Cost to Users:

      ANY-IN-CAPITALIZE-OUT is probably very low cost because it is
      more tolerant of deviations which almost surely already exists between
      implementations, and among users who have made various assumptions
      about what implementations might or should do.

      CASE-SENSITIVE is a slightly incompatible change, but
      probably a lot of programs don't use either of these functions.
      Of those that do, some usages don't depend on anything other
      than that (NAME-CHAR (CHAR-NAME x)) will work.  In any case, most
      applications that uses these are probably fairly easily to check
      by hand even though mechanical checking probably would not work
      very well.

    Cost of Non-Adoption:

      Divergence among implementations.  Potential portability problems
      from skews of interpretations.  New implementations would not know
      clearly what their rights and responsibilities were.

    Benefits:

      A clearer specification.

    Aesthetics:

      ANY-IN-CAPITALIZE-OUT is less aesthetic because it has a special
      case for one-character strings.

      CASE-SENSITIVE is generally more aesthetic.

    Discussion:

      KMP thinks that mostly it's a good idea to resolve this clearly one
      way or another, and isn't incredibly fussy about the details.  He has
      a mild preference for proposal CASE-SENSITIVE because it leaves the
      greatest flexibility to the international community which has the
      English alphabet forced upon them all too often already.

Copyright 1996-2001, Xanalys Inc. All rights reserved.