This looks OK, though it seems excessively conservative. You're doing
((let ((a (foo)) (b (bar)))
(lambda (receiver)
...body...))
(lambda (x y z) ...))
=>
(let ((receiver (lambda (x y z) ...)))
(let ((a (foo)) (b (bar)))
...body...))
but only in certain restricted cases. I am not sure why you think
ordering or side effects matter here.
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...)
On Sat, Sep 19, 2009 at 10:12 PM, Taylor R Campbell <campb...@mumble.net> wrote:
> (`Integration' in the sense of `open-coding', not in the sense of
> integrating multiple return values into the system so that their
> implementation is actually correct...)
>
> Short of redesigning great swaths of the system to spread multiple
> return values on the stack, it would be nice if the compiler generated
> somewhat better code for uses of them that syntactically obviously
> don't require extra storage for them, such as
>
> (receive (x y z)
> (let ((foo (fnord)))
> (values foo (mumble foo) (frotz foo)))
> ...).
>
> Currently, SF only expands VALUES and CALL-WITH-VALUES, to transform
> that into
>
> ((let ((foo (fnord)))
> (let ((value-0 foo) (value-1 (mumble foo)) (value-2 (frotz foo)))
> (lambda (receiver)
> (receiver value-0 value-1 value-2))))
> (lambda (x y z)
> ...),
>
> for which LIAR then generates code to allocate two closures on the
> heap and to immediately call them. I've attached a patch to SF that
> makes it instead transform the above code into
>
> (let ((foo (fnord)))
> (let ((value-0 foo) (value-1 (grovel foo)) (value-2 (frotz foo)))
> (let ((x value-0) (y value-1) (z value-2))
> ...))),
>
> for which LIAR naturally generates much better code. I believe the
> transformation is very conservative: not only does it preserve the
> semantics of the program, as it of course should, but it also
> preserves any ambivalence about order of evaluation, while a more
> aggressive transformation might commit to an order of evaluation when
> the program specified none in particular.
>
> I sha'n't commit this before Chris has sorted out the macro engine and
> apparent compiler bugs, though. Comments? Objections?
>
> _______________________________________________
> MIT-Scheme-devel mailing list
> MIT-Scheme-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
>
>
_______________________________________________
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
