[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cs proposal
- To: masinter.pa@Xerox.COM
- Subject: Re: cs proposal
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 26 Oct 88 20:19 EDT
- Cc: Thom Linden <email@example.com>, "X3J13: Character Subcommittee" <firstname.lastname@example.org>, yuasa%tutics.tut.junet%utokyo-relay.CSNet@relay.cs.net, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- In-reply-to: <881025-110347-11299@Xerox>
- Line-fold: No
Date: 25 Oct 88 11:03 PDT
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
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.