From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: William ML Leslie Newsgroups: gmane.lisp.guile.devel Subject: Re: order of evaluation Date: Tue, 18 Jun 2013 11:06:41 +1000 Message-ID: References: <87li6959oz.fsf@pobox.com> <87mwqo4hr5.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1371517608 7758 80.91.229.3 (18 Jun 2013 01:06:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Jun 2013 01:06:48 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jun 18 03:06:50 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UokNl-0004dv-2O for guile-devel@m.gmane.org; Tue, 18 Jun 2013 03:06:49 +0200 Original-Received: from localhost ([::1]:56948 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UokNk-00081t-G1 for guile-devel@m.gmane.org; Mon, 17 Jun 2013 21:06:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UokNh-00081m-5Z for guile-devel@gnu.org; Mon, 17 Jun 2013 21:06:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UokNf-00028K-Ad for guile-devel@gnu.org; Mon, 17 Jun 2013 21:06:44 -0400 Original-Received: from mail-oa0-x234.google.com ([2607:f8b0:4003:c02::234]:64670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UokNf-00025F-0j for guile-devel@gnu.org; Mon, 17 Jun 2013 21:06:43 -0400 Original-Received: by mail-oa0-f52.google.com with SMTP id g12so4343789oah.11 for ; Mon, 17 Jun 2013 18:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=MAzBPnGPlyscyMKwvbrShayxrQ+g3C+mSYMibc+1kdk=; b=mgWtA60Men5lL5K4WNY01ZbWv0EJzN0s5RETihcCcEIws7k1ifowKfCo+K+ot66Pe1 9AbJ3TsetVZWhjWOAsII1PzmX6fkkVrYuskVerIYWmKPHaVaIRy+rZXWTETA7DzsNOK/ Il35igVKNV0DbedA4mqIUuhG1FFF7Y8I3dJ3fXNkVBAGKUCg4x/4bA01EHtC8XfKngel oEPjSHL/seTtDKZcsjXZfxYN1nuR1UrYx+7j1egw76kVMyJOx3ssLyZKajZy8cLe6Eb5 zCUxbMqO4+VSZMi9PV3l1yRaLPx+3PFmsczfSggF1cpnmSlHOqapNofJJUy5JiSMAA2s pBsQ== X-Received: by 10.60.97.68 with SMTP id dy4mr10587028oeb.90.1371517601791; Mon, 17 Jun 2013 18:06:41 -0700 (PDT) Original-Received: by 10.182.251.202 with HTTP; Mon, 17 Jun 2013 18:06:41 -0700 (PDT) In-Reply-To: <87mwqo4hr5.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c02::234 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16497 Archived-At: On 18 June 2013 06:14, Andy Wingo 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.