From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: CPS Update Date: Sat, 16 Feb 2013 14:14:55 -0500 Message-ID: <871ucgrryo.fsf@tines.lan> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1361042125 11003 80.91.229.3 (16 Feb 2013 19:15:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Feb 2013 19:15:25 +0000 (UTC) Cc: guile-devel To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Feb 16 20:15:46 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 1U6nEg-00018i-4a for guile-devel@m.gmane.org; Sat, 16 Feb 2013 20:15:46 +0100 Original-Received: from localhost ([::1]:34283 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U6nEM-00056Z-AL for guile-devel@m.gmane.org; Sat, 16 Feb 2013 14:15:26 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U6nEJ-00056J-Hz for guile-devel@gnu.org; Sat, 16 Feb 2013 14:15:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U6nEH-0003JB-Ok for guile-devel@gnu.org; Sat, 16 Feb 2013 14:15:23 -0500 Original-Received: from world.peace.net ([96.39.62.75]:49542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U6nEH-0003DV-Ko for guile-devel@gnu.org; Sat, 16 Feb 2013 14:15:21 -0500 Original-Received: from c-98-217-64-74.hsd1.ma.comcast.net ([98.217.64.74] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U6nDz-0000j0-90; Sat, 16 Feb 2013 14:15:03 -0500 In-Reply-To: (Noah Lavine's message of "Sat, 16 Feb 2013 11:29:11 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:15752 Archived-At: Noah Lavine writes: > Oh, you're right. I was thinking about that because I don't run the > Tree-IL optimizers when I test it, so I don't get any Tree-IL > primitives. I think you should be running the existing tree-il passes before you convert to CPS. As I pointed out earlier, many optimizers will not be able to work well after conversion to CPS, fundamentally because CPS loses information about where order of evaluation is unspecified. Furthermore, some of the existing passes make important simplifications to the resulting tree-il. For example, the code in fix-letrec.scm eliminates all nodes, so that's one less thing for you to have to implement. Primitives.scm marks primitives explicitly using tree-il nodes, so that later code doesn't have to make thorny assumptions about what variables should be considered primitives. > I think I read that loading GOOPS turns things like '+ into generic > operations - that might be a case where this matters a lot. No, because GOOPS has a special mechanism for cases like '+': they are called "primitive generics". When numerical operations are unable to handle the argument types provided, they calls 'scm_wta_dispatch_*'. Therefore, adding new methods to numerical operations does not involve changing their bindings. This is good because it means that you can extend numerical operations without slowing them down at all for built-in numbers. > I have thought a bit about how to fix this. The module system already > allows us to be notified whenever a variable changes, so it would be > easy to watch all of the variables in (guile) and recompile procedures > when they change. I might take a look at this soon. This would be nice too, of course, but I warn you that it's a can of worms. In the general case, it involves on-stack replacement, because you might need to recompile a procedure that's currently in the middle of being run, and thus currently has activation records on the stack(s). Thanks for you work on this, Noah! Mark