[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
names for multiple SETQ/RETURN
- To: MOON at MIT-MC, RMS at MIT-MC
- Subject: names for multiple SETQ/RETURN
- From: JONL at MIT-MC (Jon L White)
- Date: Thu, 4 Sep 80 21:54:00 GMT
- Cc: GJC at MIT-MC, MACSYMA-I at MIT-MC, NIL at MIT-MC
- Cc: (BUG LISP) at MIT-MC
- Original-date: 4 SEP 1980 1754-EDT
Date: 24 August 1980 20:40-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: Multiple-value SETQ/RETURN
I don't understand why these "MSETQ" special-forms don't have the
standard names.
Well, there were several problems with the multiple-setq/multiple-return
protocol that haven't been fully resolved, but RMS's note seems to
say that the LISPM people are less worried about them. GLS had a more
extensive scheme for the S1, so if there is going to be a NIL version
which is incompatible with LISPM, the MSETQ-CALL etc are needed; but
if not, then they can merely be macroified to produce MULTIPLE-VALUE etc.
Date: 24 August 1980 01:04-EDT
From: Richard M. Stallman <RMS at MIT-AI>
Subject: Multiple-value SETQ/RETURN
There may not be any need to worry about what to do about multiple
values and PROG1. When Moon and I made multiple values work
consistently on the Lisp machine, we decided that it was reasonable
for PROG1 not to return multiple values, interpreted or compiled.
. . .
Mostly the fear about lack of generality was voiced by GJC
Date: 23 August 1980 11:22-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: Multiple-value SETQ/RETURN
. . .
You mention in NIL;NEWFUN > that the following will not
work correctly in NIL:
(MSETQ-CALL (X Y) (PROG1 (FIND-POLAR-POSITION SHIP) (FROB)))
This may make MSETQ-CALL dangerous to use in code which undergoes
macro expansion. The poor luser writes (MSETQ-CALL (X Y) (FOO)) and (FOO)
expands. Resticting what (FOO) can expand into is a gross violation
of the lisp semantic contract. Do you seriously want to introduce
a language construct for which you are unable to generate correct code?
. . .
Also, without micro-code, it may be too costly to have *assured* match
up between caller and calle as to number of items returned; if both
cooperate, there is no problem, but it not? Since VAX/NIL functions in
general do not signal the number of returned values, it may be more
difficult to get an *assured* version of MULTIPLE-VALUE-LIST.