BABYL OPTIONS: Version:5 Append  1, recent,, *** EOOH *** Date: 23 March 1981 16:21-EST From: Jon L White To: RWK, GLS cc: BUG-LISP, BUG-LISPM Re: PSETQ Date: 20 March 1981 22:58-EST From: Robert W. Kerns . . . Both LISPM and MacLisp return the first argument. Since this is parallel assignment, I'm less bothered by this than I might be, although I still think it's less than optimal from a consistancy viewpoint. MacLISP's action isn't an independent viewpoint -- I originally implemented PSETQ as a macro which returned the last value, a la SETQ, and then someone pointed out the discrepancy between that and the LISPM. Not wanting to make waves (against stone walls?), I just quietly changed it one day. However, I fear that there are now numerous places where the value of PSETQ is being used.  1, recent,, *** EOOH *** Date: 23 March 1981 17:26-EST From: Jon L White To: RWK, GLS cc: BUG-LISP, BUG-LISPM Re: PSETQ Date: 20 March 1981 22:58-EST From: Robert W. Kerns . . . Both LISPM and MacLisp return the first argument. Since this is parallel assignment, I'm less bothered by this than I might be, although I still think it's less than optimal from a consistancy viewpoint. MacLISP's action isn't an independent viewpoint -- I originally implemented PSETQ as a macro which returned the last value, a la SETQ, and then someone pointed out the discrepancy between that and the LISPM. Not wanting to make waves (against stone walls?), I just quietly changed it one day. However, I fear that there are now numerous places where the value of PSETQ is being used.  1, recent,, *** EOOH *** Date: 27 March 1981 2051-EST (Friday) From: Guy.Steele at CMU-10A To: George J. Carrette cc: kmp, rwk Re: PSETQ -- random... Sure, an "undefined value" concept is "sooo trivial to implement" -- but it is also sooo difficult to get the semantics right. (The same goes for multiple values, which were first implemented and only later really thought about: witness the fact that returning zero things was only recently made to work.) First of all, supposed the result of PSETQ is "undefined". Then what should happen when you type in a PSETQ at top level? What if you want to make variable Z unbound -- should (SETQ Z (PSETQ)) do the job? Should (UNDEFINEDP (PSETQ)) be true, or produce an error? [I'm assuming here that PSETQ "works" for zero arguments, as it obviously ought to work for any even number of arguments.] Presumably (PROGN (PSETQ A B) A) should not be an error, because the PROGN doesn't use the value of the PSETQ. On the other hand, presumably (PROGN (HACK) (PSETQ A B)) should be an error, because the PROGN does use the value of PSETQ here?? But what if the context is (PROGN (PROGN (HACK) (PSETQ A B)) (MOREHACK)) ? One finds that to get it all to work correctly you probably need the interpreter to distinguish "statement" (or "effect") contexts from "value" contexts throughout the interpretation process -- and these contexts have to be inherited in "tail-recursive" situationsa such as the last form of a PROGN. Still think it's "sooo trivial"? --Guy  1, recent,, *** EOOH *** Date: 27 March 1981 21:27-EST From: George J. Carrette To: Guy.Steele at CMU-10A cc: KMP, RWK, GJC Re: PSETQ -- random... Yes, I still think its "sooo trivial," you saw how few words it took you to cover the semantics, even though you where beating around the bush. The interpreter and compiler would need to pass along a targetting argument of "for value or effect," which is nothing new, I've seen lots of interpreters and code-walkers passing down information like that. (PSETQ) at toplevel would be an error. Tough noogies. An error is worth a thousand pictures as they say. Maybe side-effects would become less popular. Sure, the interpreter would have to be carefully coded, but there is nothing strange, it all follows from the formal definitions of the special forms. (Uhm, what formal definitions??? sigh...) Now, I'm not saying I think undefined values are a good feature. I'm just tired of hearing Lispm people say "anybody who depends on X is a fool." -gjc p.s. multiple values: "no comment"  1, recent,, *** EOOH *** Date: 28 March 1981 01:28-EST From: George J. Carrette To: Guy.Steele at CMU-10A cc: KMP, RWK, GJC Re: PSETQ -- random... I forgot to mention, (SETQ A (PSETQ)) would obviously not work for making the value of "A" undefined. Odd larguments (lexical arguments to a special form) of SETQ are evaluated for value, so the (PSETQ) returns only after a call to ERROR. Similarly there could be no UNDEFINEDP predicate, since its argument is evaluated as any argument to a function, for value. These cases make it past neither the interpreter nor the compiler. This is a static problem, very much easier than the dynamic wrong-number-of-arguments or return-values problem. I don't see any trade-offs here between efficiency and correctness. That is why I call it "trivial." It is the easy case of static type checking in targetting. If one introduces a convenience rule such as "an undefined value will be faked to NIL at the last possible momement," then the game becomes nontrivial. Sounds just like the kind of rule that people would try to use though. Oh well. -gjc  1, recent,, *** EOOH *** Date: 29 March 1981 2104-EST (Sunday) From: Guy.Steele at CMU-10A To: George J. Carrette cc: kmp, rwk Re: PSETQ -- random... I didn't say it couldn't be done -- I outlined what would have to be done. While you may think the description was short, I say it was rather long. Moreover, it involves some serious language design decisions, not just some quick hacking, and therefore to my mind cannot be regarded as trivial, "sooo" or otherwise. Also, anything that requires reimplementation of all FEXPRs isn't triviaL either. --Guy