mit-scheme-devel
[Top][All Lists]
Advanced

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

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


From: Taylor R Campbell
Subject: Re: [MIT-Scheme-devel] improving integration of VALUES and CALL-WITH-VALUES
Date: Sun, 20 Sep 2009 10:54:28 -0400
User-agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/7.7.90.+

   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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]