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

Re: [Scheme-reports] multiple values module

Three hours ago, Aaron W. Hsu wrote:
> On Tue, 24 May 2011 17:41:14 -0400, Eli Barzilay <eli@x> wrote:
> >> What I meant was this: trivially any procedure that returns
> >> multiple values could as well return a single value which is an
> >> aggregate of some sort such as a list or general vector.
> >> However, it costs something to aggregate and disaggregate this
> >> value, a cost which *some* implementations of multiple values
> >> need not pay.
> > You can't avoid the extra cost.  Implementations vary with heap or
> > stack allocation which is something that goes in a different
> > level.  In any case, your original statement of multiple values as
> > some lightweight alternative is even more wrong given this.  (The
> > historical context is first class continuations.)
> I'm not sure what you mean by the above, but I believe what John is
> referencing in the above is the efficiencies claimed by Ashley and
> Dybvig's 1994 paper [1] with which I am relatively confident you are
> familiar.

I don't think that he was referring to that since he was talking about
some implementations rather than some situations in which such
optimizations can be done.  But that's not important -- since the
point is that the same kind of optimization could be done with lists
(and a fictitious `let-cons'), or with any other kind of wrapper.  But
that's not important too, since it's all optimization details that are
irrelevant as far as justifying a language semantics goes.  (You can
see that also in the fact that (IIRC) the paper properly checks for
the right number of values, a requirement that John is eager to
ignore as long as r5rs is not explicity requiring.)

> It should be noted, however, that the claim that multiple values are
> more efficient in all cases, a claim that I do not think John is
> making, is wrong, since even with the above mentioned implementation
> strategy, if the compiler is not able to recognize certain things
> about the formulation, the above speed gains will not be observed.

Exactly -- and that's why being a more lightweight alternative is not
a consideration for defining the language.  IOW, if there was some
universally applicable optimization it would be questionable as a
factor in that context, but with covering only some cases, the
situation is that both approaches are practically the same in terms of
additional overhead.

          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Scheme-reports mailing list