unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: William ML Leslie <william.leslie.ttg@gmail.com>
To: guile-devel <guile-devel@gnu.org>
Subject: Re: order of evaluation
Date: Tue, 18 Jun 2013 11:06:41 +1000	[thread overview]
Message-ID: <CAHgd1hG3=6jO0_z-ftSA6MKa4Ytspq78-ycq57KhUPO_6LUrNA@mail.gmail.com> (raw)
In-Reply-To: <87mwqo4hr5.fsf@pobox.com>

On 18 June 2013 06:14, Andy Wingo <wingo@pobox.com> 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

Notice:
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.



  parent reply	other threads:[~2013-06-18  1:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-17 10:10 order of evaluation Andy Wingo
2013-06-17 13:49 ` Noah Lavine
2013-06-17 20:14   ` Andy Wingo
2013-06-18  0:39     ` Noah Lavine
2013-06-18  1:06     ` William ML Leslie [this message]
2013-06-23 13:46 ` Ludovic Courtès
2013-07-03 18:57 ` order of evaluation, letrec-values, and define-values Mark H Weaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHgd1hG3=6jO0_z-ftSA6MKa4Ytspq78-ycq57KhUPO_6LUrNA@mail.gmail.com' \
    --to=william.leslie.ttg@gmail.com \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).