From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.devel Subject: Re: summary: lilypond, lambda, and local-eval Date: Sun, 18 Dec 2011 17:19:34 +0100 Organization: Organization?!? Message-ID: <871us1x36x.fsf@fencepost.gnu.org> References: <87r506uodd.fsf@pobox.com> <87pqfpj7e3.fsf@netris.org> <87aa6skika.fsf@netris.org> <878vmaicb6.fsf@netris.org> <87vcperufl.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1324225200 12926 80.91.229.12 (18 Dec 2011 16:20:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 18 Dec 2011 16:20:00 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Dec 18 17:19:57 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RcJSu-0001ed-Re for guile-devel@m.gmane.org; Sun, 18 Dec 2011 17:19:57 +0100 Original-Received: from localhost ([::1]:57304 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcJSu-0005ST-Bc for guile-devel@m.gmane.org; Sun, 18 Dec 2011 11:19:56 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:52726) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcJSs-0005SN-0a for guile-devel@gnu.org; Sun, 18 Dec 2011 11:19:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RcJSr-0008Ux-0R for guile-devel@gnu.org; Sun, 18 Dec 2011 11:19:53 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:59807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcJSq-0008Ur-N4 for guile-devel@gnu.org; Sun, 18 Dec 2011 11:19:52 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RcJSo-0001dD-Q8 for guile-devel@gnu.org; Sun, 18 Dec 2011 17:19:50 +0100 Original-Received: from p508e9bc1.dip.t-dialin.net ([80.142.155.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Dec 2011 17:19:50 +0100 Original-Received: from dak by p508e9bc1.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Dec 2011 17:19:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 38 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508e9bc1.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) Cancel-Lock: sha1:8ryFW8t2GyHgAn9sHMpWu/zX71c= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:13154 Archived-At: Let me first state that this thread is arguing at a depth where the only contributions that remain for me to make are syllogisms without an actual knowledge of what I am talking about. In order not to appear ungrateful, I will do that, but there will be little point in expecting me to be of assistance in judging their merit. Noah Lavine writes: > If I understand correctly, Mark wants to restrict the set of variables > you can access to those you could access through normal Scheme code. > This is an issue because psyntax happens to provide a way to access > more variables than standard Scheme. If this is the case, I think we > should absolutely restrict it to standard Scheme, because letting you > access everything psyntax can access a) is not Scheme and b) restricts > our future implementation choices. If psyntax accesses more than Scheme can access while doing a task that is worth doing, what chance would there be in giving Scheme the power to access what psyntax can? If exporting enough of the compiler environment to be useful for implementing multiple compilation units sharing lexical environments is feasible, what are the implications for splitting a compilation into separate units when the extent of psyntax is not similarly involved? In short: where should one draw the line in a way that makes best use of already done compilations without having to redo too much to be of practical use? > In general, this thread has been very, very impressive. Thanks a lot > to everyone who has been working so hard on this. Agreed. -- David Kastrup