[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
multiple return values
> 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?