[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
your proposed revision
- To: Masinter.PARC@Xerox.COM
- Subject: your proposed revision
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 7 Jan 88 03:25 EST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: <880106-232940-6463@Xerox>
This looks better, and maybe it's the best I can hope for within this group,
which apparently largely disagrees with me.
But for the record, I'm absolutely not happy with any recommendation that
people run out and implement any of this unless we name the subsets which we
are encouraging them to implement in some way that does not change daily.
If it does turn out that we change any of these, we may end up feeling guilty
for having encouraged people to adopt what even now seem like compatible
changes because in the future we will have to consider any further change as
not only potentially in conflict with CLtL but also potentially in conflict
with the supposedly non-binding changes we announced earlier and strongly
encouraged people to rush out and implement.
Moreoever, even what seems like a compatible change will cause headache for
people who learn to depend on the new feature and then port to a CL that
doesn't have it. Since I myself am involved in the maintenance of a Lisp,
and since I'm very conservative about what goes into that Lisp, I will be
unhappy if our users come complaining to me that other lisps support one
of these extensions (with no official status) and claims that it is my Lisp
which is faulty for not providing it. I think it is unfair of this committee
to put me in such a position and I think that's exactly what you are doing.
I will be in a damned-if-i-do and damned-if-i-don't position if you make
these changes non-binding while still urging everyone to rush out and
implement them. I would rather see you simply observe that it is possible
to make some extensions now if they want, but not do any form of encouraging
or urging. Even an explicit plug for implementors who want to maintain
the status quo would be in order in my opinion.
In any case, I think that explicit wording should be given in your message
saying that even if they provide these proposed changes, they should document
them as deviations from the standard. Your remarks about "proposed changes
likely to..." are not clear about whether this is a phrase they should
say to themselves to keep their conscience clean or to their customers for
the sake of truth in advertising. I think both, but I can see some people
preferring to do only the former.
Mostly, I feel like I am saying the same thing over and over and getting
nowhere. I think you understand my position, so if I haven't convinced you
of its importance either to me personally, to me as an implementor, or to
the community at large, perhaps it is about time for me to give up and be
silent. Just didn't want anyone to construe that silence as some form of