Date: Sat, 19 Sep 2009 22:58:20 -0700
From: Chris Hanson <c...@chris-hanson.org>
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.
_______________________________________________
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
