[no subject]

[mike@a]

    Date: 26 Jun 86 15:36 PDT
    From: Masinter.pa@Xerox.COM
    
    Sounds like I wasn't clear enough.
    
    When I suggested portable programs "stick within the set of standard
    characters" I was referring to "the Common Lisp character set" as
    defined on pp 20-21 of "Common Lisp the Language" by Guy L. Steele Jr.
    as follows:
    
    "The Common Lisp character set consists of a space character #\Space, a
    newline character #\Newline, and the following ninety-four non-blank
    printing characters or their equivalents..."
    
    It looks awfully specific to me, and I'm not sure what our friends at
    IBM or Japan would be chuckling about.
    
    In reply to KMPs other points:
    
    "It's important to distinguish between implementation dependent behavior
    and unpredictable behavior. Many things in Common Lisp are conceptually
    well-defined even though they vary from implementation to
    implementation. For example, the behavior of (1+ MOST-POSITIVE-FIXNUM)
    varies in detail  from implementation to implementation, but
    conceptually it does not.  I don't think that it's inappropriate to
    describe a program as having useful commands bound to keys and to tell
    the user to type "?" to see a list of the commands available."
    
    I agree whole-heartedly with this analysis and the appropriateness of
    the situation you describe.
    
    "The issue is much bigger than you make it out to be and if you claim it
    to be fatal, then I claim you're attacking the whole notion of whether
    CL can be portable..."
    
    I object to your claim: I firmly believe that CL can be portable and I'm
    making no such attack. That's the point of this whole discussion. I
    think that this is in fact one of the few intrinsicly non-portable parts
    of the language.
    
    I agree that CHAR-BITS-LIMIT is in the same class as
    "MOST-POSITIVE-FIXNUM". The issue as I see it is: does this abstraction
    *encourage* or *discourage* users from writing portable programs? 
    
    I claim that this particular feature works against portability: It is my
    belief that having "char-bits" in the book will encourage users who are
    working in an implementation which supports "char-bits" to rely upon
    "char-bits" in their programs, with a nod to the fact "well, those
    lusers without char-bits just can't use this program".
    
    If char-bits were *not* in the standard,  then the writer of a portable
    program would set aside a table somewhere, which said:
    
    ; implementation-dependent table of character codes and their functions
    
    #\control-A  delete-next-character
    #\control-R retype-line
    
    
    and clearly identify that these were not "standard" (in the sense of pp
    20-21) characters. Let me put it in terms of a more definite proposal in
    terms of chapter and verse:
    
    a) eliminate constants char-code-limit, char-font-limit and
    char-bits-limit, and instead have a constants:
    
    char-integer-limit		[Constant]
    The value of char-integer-limit is a non-negative integer that is the
    upper exclusive bound on values produced by the function char-integer.
    ...
    
    string-char-integer-limit	[constant]
    The value of string-char-integer-limit is the upper exclusive bound on
    values produced by the funcion char-integer for characters which satisfy
    string-char-p.
    
    [Implementation note: older Common Lisps can implement this by 
    (defconstant char-integer-limit (+ char-code-limit  char-font-limit
    char-bits-limit)) 
    (defconstant string-char-integer-limit  char-code-limit)]
    
    b) change the wording of char-upcase and char-downcase to omit
    references to "characters with non-zero bits". [note: I detect an
    inconsistency in the description of char-upcase on p. 241, which in the
    second paragraph says that it returns a character object with the same
    font and bits attributes but with possibly a different code, and in the
    last paragraph says that they have no effect on characters with non-zero
    bits attributes]
    
    c) eliminate functions char-code, char-bits, char-font, code-char,
    make-char from the standard. 
    [Compatibility note: users with older common lisp programs may want to
    define char-code as (mod (char-int char) string-char-integer-limit)) and
    similarly make the other ones as transforms on char-integers]
    
    d) eliminate the constants char-control-bit char-meta-bit char-super-bit
    char-hyper-bit  and the functions char-bit set-char-bit. [Compatibility
    note: users with older common lisp programs who want to use these
    features can define these constants as 1 2 4 8 respectively, and define
    
    (defun char-bit char name
    	(int-char (logtest (int-char char)
    			(* string-char-integer-limit (ecase name (:control 1) (:meta 2)
    ...))))))