[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

names for multiple SETQ/RETURN



    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.