[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: IF-BODY (Version 7)
- To: CL-CLEANUP@Sail.stanford.edu, X3J13@Sail.stanford.edu
- Subject: Issue: IF-BODY (Version 7)
- From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
- Date: Wed, 17 Jun 87 18:15 EDT
- Cc: Masinter.pa@Xerox.COM
- In-reply-to: <870616-170738-108@Xerox>
- Line-fold: No
Date: 16 Jun 87 17:07 PDT
From: Masinter.pa@Xerox.COM
If this proposal is not accepted, it should be mandated that
extensions to IF are explicitly disallowed. The status quo, where there
is a tacit acceptance of extensions which are not portable and difficult
to detect, is unacceptable.
I'd like to state emphatically that I do not agree with this point of
view about extensions. The original point of Common Lisp was to be a
large common subset, designed to allow portable programs without
stifling extensions and experimentation, and without creating massive
compatibility problems. (I say "massive" because that's what would
happen if a policy of such explicit disallowal were applied across the
board.) If this attitude had prevailed at the beginning, there would
have been no Common Lisp.
I take the position that there ought to be tools that specifically help
you make sure that your program can be expected to run portably in other
CL implementations. The extended IF is not particularly "difficult to
detect" for such a tool; in fact, it's very easy. Meanwhile, the
extended implementation need not print out any warnings.
Such a portability tool is needed for other reasons: even if a
particular CL implementation doesn't have any "extensions", nevertheless
it necessarily makes choices about things that the CL manual leave up to
the implementation, and a program could be depending on those choices.