[Top][All Lists]

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

Re: order of evaluation

From: William ML Leslie
Subject: Re: order of evaluation
Date: Tue, 18 Jun 2013 11:06:41 +1000

On 18 June 2013 06:14, Andy Wingo <address@hidden> wrote:
> If I understand correctly, I think this is going in the wrong
> abstractive direction -- CPS is nice because it's a limpid medium for
> program transformations that also corresponds neatly to runtime.  With
> this sort of thing we'd be moving farther away from the kind of code we
> want to emit.  Dunno.

Emit where?

Noah's example of building a continuation graph represents the
unspecified order of argument evaluation, but why stop there?  For the
most flexibility during optimising, a program may as well be
represented as a directed graph, with several classes of edge labels,
allowing you to express commutativity more cleanly.  For example,
stores can be re-ordered if one sets a car and the other a cdr, and
stores into freshly-allocated pairs with those into pairs that come
from the environment.  The 'Context' in [0] (Effect, Test, Value, App,
and probably Identity in a language with mutabality) is then just a
lattice which describes how to remove redundant edges and nodes from
that graph.

Since you're implementing an AOT compiler for a safe language, such a
mechanism may actually be useful.  I don't think it has been when I've
played with it before, partially because making the most of the graph
means using information taken from other functions, which introduces
compile-dependencies that need to be invalidatable at runtime (in the
languages I've targetted, anyway), and partially because I've always
tried to enlarge the set of edge labels with region variables, which
can be non-trivial, especially in a dynamic language.

But if taking advantage of the unspecified argument order is the sort
of thing you want to do, instruction graphs are possible, just a lot
of work.  If you just want to represent the fact that these
expressions are in argument position for input to the interpreter
(which may do something fancy with those later) then a (regular,
unordered) let is simpler.

[0] Oscar Waddell and R. Kent Dybvig, Fast and Effective Procedure Inlining

William Leslie

Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely may reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to deny you those rights would be illegal without
prior contractual agreement.

reply via email to

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