Re: [Scheme-reports] multiple values module

[Eli Barzilay <eli@x>]

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
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports