[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: READ-CASE-SENSITIVITY (Version 1)
- To: cutting.pa@Xerox.COM
- Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 15 Feb 89 18:06 EST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, email@example.com, CL-Cleanup@sail.stanford.edu, firstname.lastname@example.org
- In-reply-to: <890215-135333-1329@Xerox>
That's quite a reasonable point -- for *READ-BASE* especially --
however, I am not devoid of remarks to make...
1. It is arguably necessary to vary *PACKAGE* in order to
achieve a certain kind of modularity. Indeed, a certain amount
of confusion is almost intentional in the package system in
this regard. There is `deliberate ambiguity' in unqualified
symbols, you might almost say. I certainly grant you that
it leads to troubles every now and then, though.
2. Of late I've been seriously questioning whether anything so
important as the base ought to be allowed to fluctuate. We
certainly pay a big price for that flexibility. Nevertheless,
both this and *READTABLE* do indeed provide creative ways for
modules to screw each other.
3. *READTABLE* is already powerful enough to provide what you need
if only there were a way of suitably modifying a readtable.
4. One of the reasons we can survive at all with *PACKAGE*, etc.
is that good programmers know there is a finite set and they
carefully bind the ones that matter around individual calls to
READ, or around module boundaries, or whatever. To introduce
a new one at this point is the same kind of destabilizing thing
as introducing a new special form. (Of course, since we've recently
introduced some new special forms, this isn't a hard and fast
argument, but it is a moral dilemma we had to contend with when
adding those special forms and I think we should have to wrestle
with it here anyway.)
5. Just because there is precedent for problem doesn't mean we should
invite more problems based on that precedent. You yourself admit
that *PACKAGE* and friends invite problems.
1 and 2 are just my personal thoughts and I don't expect them to
carry any argumentative weight.
4 and 5 are issues I think we can't ignore.
The option of doing 3 is compelling to me. I think this is the past
of least resistance. I think it is just complicated enough that naive
users will not do it accidentally and then run into problems, yet
straightforward enough that no one who needs case preservation will
have any trouble figuring out what to do.
I think someone should therefore instead propose that we introduce some
operation like SET-CHARACTER-CASE-TRANSLATION (or perhaps something more
general like Genera's SET-CHARACTER-TRANSLATION, which I think -- I didn't
look up its documentation recently -- allows you to say that arbitrary
chars are translated to arbitrary others).