Re: [MIT-Scheme-devel] improving integration of VALUES and CALL-WITH-VALUES

[Chris Hanson]

I think it would be useful to amend the comments in the patch to show
the additional arguments.  Without those arguments, there's no
justification for the conservative treatment.

Alternatively, you could restrict the optimization to one without
addtional arguments, and be less conservative.

On Sun, Sep 20, 2009 at 7:54 AM, Taylor R Campbell <address@hidden> wrote:
>   Date: Sat, 19 Sep 2009 22:58:20 -0700
>   From: Chris Hanson <address@hidden>
>
>   This looks OK, though it seems excessively conservative.  You're doing
>
>   [snip]
>
>   but only in certain restricted cases.  I am not sure why you think
>   ordering or side effects matter here.
>
> In
>
> ((let ((a (foo)) (b (bar)))
>   (lambda (x y)
>     ...))
>  (mumble)
>  (frotz)),
>
> the input program has expressed that there is no order dependency
> between (foo), (bar), (mumble), and (frotz).  Transforming this into
>
> (let ((x (mumble)) (y (frotz)))
>  (let ((a (foo)) (b (bar)))
>    ...)),
>
> while correct, destroys this information, which I understand LIAR uses
> in some capacity, by saying that (mumble) and (frotz) must both happen
> before either of (foo) and (bar).  Changing this is straightforward,
> though, just by omitting the test for whether the operands have side
> effects.  With only slightly more effort it could also be made to
> transform
>
> ((begin (foo) (bar) (lambda (x y) ...))
>  (mumble)
>  (frotz))
>
> into
>
> (let ((x (mumble)) (y (frotz)))
>  (foo)
>  (bar)
>  ...).
>
> I didn't do these because the more conservative transformation
> suffices to improve code that uses VALUES and CALL-WITH-VALUES, and I
> don't think such idioms arise much elsewhere.
>
>   However, isn't the following always semantics preserving (modulo renaming):
>
>       ((let ((a (foo)) (b (bar)))
>          (lambda (receiver)
>            ...body...))
>        (lambda (x y z) ...))
>
>        =>
>
>       (let ((a (foo))
>             (b (bar))
>             (receiver (lambda (x y z) ...)))
>         ...body...)
>
> Probably, but I think that would be more complicated to implement
> (particularly for nested cases: (receive (x y z) (let ... (receive (p
> q r) (values ...))) ...)).  The code I wrote doesn't do any hairy BVL
> munging -- it just moves around combinations' operators and
> procedures' bodies.  I doubt whether LIAR generates better code for
> one form or another, particularly since the subsequent use of RECEIVER
> will be integrated if it was introduced by VALUES.
>