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

[Chris Hanson]

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 <address@hidden> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
>
>