multiple return values

[David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>]

> Date: Wed,  1 Apr 87 21:51:51 EST
> From: Chris Hanson <CPH@mc.lcs.mit.edu>
> 
>     Date: Tue, 31 Mar 87 22:13:26 EST
>     From: Jonathan A Rees <JAR at AI.AI.MIT.EDU>
> 
>     I would strongly oppose the Common Lisp multiple value semantics.  I
>     find it to be very distasteful.  If this means that the language has no
>     multiple values primitively, and I have to implement semantics #1 myself
>     using lists or closures or whatever, that's fine with me.
> 
>     If I have many sympathizers then I'd say it appears that we're
>     as deadlocked as we were last time this came up...
> 
> I think that I agree with JAR... I've just got back from vacation and
> have not yet read all the mail on this (at 1200 baud, I'll wait for
> work tomorrow!), but I am very disturbed by the direction this is
> taking.  I don't see a need for a complicated semantics!  I'll reply
> more fully later when I've had a chance to read all of this.

I hope we can at least agree on the names and the syntax for a
standard facility.  I agree that we shouldn't STANDARDIZE on anything
complicated, but that we should have the basis for extensions in the
direction of Common Lisp for those of us that want it.

> Date: Sun, 29 Mar 87 02:29:12 EST
> From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
>
> I will confine myself to reminding you of what I said the last time this
> subject was raised:  Any implementation of multiple-values that doesn't
> have the property that ordinary continuations (for example the continuation
> passed to F in (+ (F) 3)) will accept and ignore extra values has missed
> the point of multiple values.

This is why I prefer alternative #2.

> Let me try putting it another way:  If you decide on a semantics for
> multiple values that has the property that a correct implementation can be
> written in straight R^3RS Scheme, then what have you accomplished?  You
> haven't given the users anything they couldn't have written for themselves.
> (Yes, perhaps you can arrange to implement it more efficiently, but since
> when has that been the the spirit of the language?)

I would prefer this to no agreement at all.  Can we avoid deadlock?

Regards,
David Bartley