Re: cs proposal

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 25 Oct 88 11:03 PDT
    From: masinter.pa@Xerox.COM

    The proposal did not ever say explicitly, and I feel strongly that it
    should, that in fact Common Lisp *requires* absolutely no changes in order
    to support extended character sets. The language as specified in CLtL is
    entirely adequate to allow handling of multiple, international character
    sets. The implementation of Xerox Common Lisp, now available on Xerox 1100
    series workstations and Sun 3 and Sun 4 workstations, is an existance
    proof.

So is Symbolics Genera.  However, I doubt that programs and data files
written to exploit extended character sets are portable between
Symbolics and Xerox (Envos).  For programs, the primitives defined by
Common Lisp are insufficient for meaningful manipulation of multiple
character sets.  For data files, Common Lisp says nothing about how
characters are represented.

Isn't portability between implementations the whole reason for additional
standardization in this area?

Most of your comments are consistent with the comments that Symbolics
sent in, I think.  Also your desire for better specification of such
things as what alphabetic case means in international character sets is
consistent with comments from International Lisp Associates that I saw.

    The discussion of the proposal frequently confounds two separate
    distinctions, of "backward compatibility" and "portability". Our primary
    goal is to allow "portable" programs -- programs that, if written in the
    standard language, will run unchanged in all implementations that support
    the standard language.  We try to achieve that while also supporting
    "backward compatibility" -- programs that run in current implementations of
    Common Lisp should continue to work correctly unchanged. I fear that the
    proposal, in the name of efficiency and backward compatibility,  damages
    the portability of the resulting language, because it allows programs to
    rely on implementation-dependent details of the nature of strings. It
    damages backward compatibility, because valid programs that manipulated
    strings will no longer be correct. And it does not make a convincing
    argument that it has actually solved the problem of *efficient*
    international character set handling.

I'd like to see some more detail on these allegations, particular the
one about allowing programs to rely on implementation-dependent details,
since unlike your other comments I don't agree with them, or maybe I
don't know what exactly you're saying.

    I think you've done an admirable job of establishing the scope and extent
    of possible changes to Common Lisp in the area of character handling.
    However, I would like to see the proposal split up into separate "issues"
    which each have their own pros and cons.

I think this is a good idea for issues that are truly separable, such as
removing char-bits, but splitting up the kernel of the proposal seems to
me to be just more work for both writers and readers, so I'd rather
see the main proposal remain all in one piece.