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: Autocompilation/LilyPond Date: Mon, 05 Mar 2012 12:57:15 -0500 Message-ID: <87ipijx75w.fsf@netris.org> References: <87vcmj1gwn.fsf@fencepost.gnu.org> <87vcmjxiu5.fsf@netris.org> <87sjhnyuwl.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1330970392 7059 80.91.229.3 (5 Mar 2012 17:59:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 5 Mar 2012 17:59:52 +0000 (UTC) Cc: guile-devel@gnu.org To: David Kastrup Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Mar 05 18:59:51 2012 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 1S4cCM-0005bG-7G for guile-devel@m.gmane.org; Mon, 05 Mar 2012 18:59:50 +0100 Original-Received: from localhost ([::1]:41618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4cCL-0001vh-NH for guile-devel@m.gmane.org; Mon, 05 Mar 2012 12:59:49 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4cC0-0001uE-JG for guile-devel@gnu.org; Mon, 05 Mar 2012 12:59:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4cBy-0008FJ-PI for guile-devel@gnu.org; Mon, 05 Mar 2012 12:59:28 -0500 Original-Received: from world.peace.net ([96.39.62.75]:46572) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4cBy-0008F2-Ku; Mon, 05 Mar 2012 12:59:26 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1S4cBq-0000p4-Bo; Mon, 05 Mar 2012 12:59:18 -0500 In-Reply-To: <87sjhnyuwl.fsf@fencepost.gnu.org> (David Kastrup's message of "Mon, 05 Mar 2012 15:39:06 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:14013 Archived-At: David Kastrup writes: > Mark H Weaver writes: > >> David Kastrup writes: >> >>> with the stable release 2.16 of LilyPond looming around the corner, it >>> will become imminent soon to think about supporting Guile 2.0. >>> >>> Previous attempts have mostly exploded around the problem that we have >>> something like >>> >>> (for-each ly:load init-scheme-files) >>> >>> in our lily.scm file, and the auto-compiler attempts to compile all >>> of those files independently as far as I understand. Unfortunately, >>> some of them contain macro definitions that other files rely on. >>> >>> Personally, I think it would make sense if we could get the >>> autocompiler to treat the whole blob of files as _one_ unit, and >>> recompile the unit if it gets out of date. >> >> I'm not sure that would help much. There's a deeper problem that you >> should be aware of. In Guile 1.x, macro uses within procedures are >> not expanded until the procedure is evaluated. In Guile 2, macros are >> expanded as soon as the procedure is defined, even if compilation is >> turned off. This means that functions can only use macros that were >> previously defined. > > I don't think that making this condition hold would be really hard. > LilyPond has a rather carefully selected load order in several stages, > so use-before-definition, whether in the context of macros or not, > should be more the exception than the rule, and only require smaller > rearrangements. Excellent! As long as you load everything in the right order, such that macros are defined before they are used, I don't see why there should be any other problems related to macros and compilation. Mark