IF-BODY
CLtL defines the special form IF as taking either two or three arguments. Some implementations extended IF to allow more arguments. In those implementations, using the extended IF syntax will not generate a warning. Code using the extended IF is not portable.
IF, making it expressly legal to supply an implicit-PROGN of `else' forms using the syntax (IF test then {else}*).IF NIL 'THEN 'ELSE 'MORE)
according to CLtL is an error. Under IF-BODY:LEGAL, this would return MORE.
IF NIL 'THEN 'ELSE 'MORE) "is an error".
Some implementations already provide the proposed extension.
A few implementations provide alternate keyword-driven extensions that are incompatible with the proposed extension.
Some implementations signal an error if other than two or three arguments are passed.
Some implementations quietly ignore additional arguments to IF, returning only the value of the third argument when the first argument is false.
The problem is rightly due to the user, but users typically expect that they should be warned about such problems. Unfortunately, however, both the Lisp which allows the extended syntax and that which fails to signal an error about the invalid syntax are within their rights as currently stated.
It is not adequate to encourage implementors to warn about non-standard uses since the only implementations which will implement the extension are ones who think it is a good idea to use the feature, and people are not inclined to warn about things they think are a good idea to use.
In some implementations which have incompatible extension strategies, such as keyword-driven facilities, the cost may be slightly higher because this is an incompatible change.
Pro: When there are multiple else clauses, the alternatives (IF test then (PROGN else1 else2)) or (COND (test then) (T else1 else2 else3)) are cumbersome. A natural extension of IF provides economy of expression in some circumstances. Experience in user communities where extended IF is available show that few users object to its presence; most are happy about the syntactic flexibility it provides. By allowing the extended IF, the resolution of this controversial programming style issue is left to the user rather than being forced by the language designers. Those who prefer the symmetry of the (IF test then else) syntax are free to use it as needed or even exclusively without infringing on the desires of others who may wish to use the extended syntax.
Con: The (IF test then else) syntax is symmetric. The asymmetry of (IF test then {else}*) syntax can be visually confusing. IF was intended to be the simplest conditional form, from which all the others are built. This proposal makes it more complex.
The committee found it nearly impossible even to arrive at a version of the problem statement and proposal which could be endorsed as a fair representation of the issue. In particular, this version has not been endorsed or agreed upon by all members the committee.
Some members feel very strongly that this proposal should be adopted, while others object violently, not only to the proposal but to the manner in which it arose. How can we balance flexibility against simplicity in the language syntax? How seriously should we consider compatibility with current extensions to Common Lisp?
The problem with IF-BODY arose as a serious compatibility issue in porting a major Common Lisp application (MACSYMA).
There was strong sentiment that the allowed variance of IF is a serious barrier to portability, and wants to see it fixed. Those who support this proposal believe it is the minimally disruptive way to fix the problem. 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.
There was concern about the potential precedent which could be set by using compatibility concerns as a lever to introduce all kinds of unwanted idiosyncratic extensions present in a few implementations.
It was suggested that the mere fact that some people like an extensionis not sufficient reason to put it into the language, but is sufficient reason to -discuss- putting it into the language.
It was noted that one of the original reasons for including IF in the language was to have a simple primitive that can easily be recognized, by people and by program-walkers alike, as being the simplest conditional and not having implicit PROGNs as do WHEN, UNLESS, and COND.
The supporters argue that the language is already so cluttered that worrying about such a tiny change to IF is unwarranted (e.g., consider the complexity of LAMBDA). If the only concern was primitive simplicity, we should just redefine the layer at which simplicity is achieved by letting LISP:IF be a macro that expands into PRIMITIVE:IF which has simpler semantics but which no one has to be stuck programming with (if they don't want to). While users could make their own JDOE:IF macro that has this extension, this is likely to be a such a common extension, it should be adopted as part of the standard.
TIMESROMANTITANTITAN TIMESROMAN ¾
|m[í ö÷ Jø"zº*start* 02071 00024 USh Return-Path: <@SAIL.STANFORD.EDU:barmar@Think.COM> Received: from SAIL.STANFORD.EDU by Xerox.COM ; 22 JUN 87 12:33:28 PDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 12:07:29 PDT Received: from occam by Think.COM via CHAOS; Mon, 22 Jun 87 15:07:19 EDT Date: Mon, 22 Jun 87 15:04 EDT From: Barry Margolin <barmar@Think.COM> Subject: Re: IF with multiple ELSE To: Cris Perdue <cperdue@sun.com> Cc: DLW@alderaan.scrc.symbolics.com, x3j13@sail.stanford.edu In-Reply-To: <8706221712.AA05089@clam.sun.com> Message-Id: <870622150454.2.BARMAR@OCCAM.THINK.COM>
Date: Mon, 22 Jun 87 10:12:52 PDT From: cperdue@sun.com (Cris Perdue)
It seems clear that this is one of those "matter of taste" issues, depending a lot on personal preference and what you're accustomed to. My experience has been that electronic mail discussions are not very useful for such issues. Perhaps normal X3J13 channels would be more effective.
This is more than a "matter of taste" issue. It is also a readability, clarity, and error-proneness issue. My thanks are to JonL for bringing this up. My personal vote has been for if with "then" and "else" keywords and multiple "else" clauses ever since I first began to use Interlisp-10 several years ago.
If-then-else-etc. in fact is a well-established part of my personal Lisp programming practice. Let's pursue this issue further.
Unless someone plans on doing some human factors experiments, we will not be able to make any objective decision about the "readability, clarity, and error-proneness issue". The matter of taste that Dan referred to was the fact that different people find the different forms more readable, clear, or error-prone. Without concrete data, taste is all we can go by. What we've seen so far is lots of people saying, "well, I've been using FOO-LISP's WHIZ-BANG-IF feature for years, and it's really great." Lots of people swore by Interlisp's DWIM feature, but it wasn't put into CL either.
barmar