From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: summary: lilypond, lambda, and local-eval Date: Sun, 18 Dec 2011 16:24:53 -0500 Message-ID: References: <87r506uodd.fsf@pobox.com> <87pqfpj7e3.fsf@netris.org> <87aa6skika.fsf@netris.org> <878vmaicb6.fsf@netris.org> <87vcperufl.fsf@pobox.com> <871us1x36x.fsf@fencepost.gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: dough.gmane.org 1324243506 32650 80.91.229.12 (18 Dec 2011 21:25:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 18 Dec 2011 21:25:06 +0000 (UTC) Cc: guile-devel@gnu.org To: David Kastrup Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Dec 18 22:25:01 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 1RcOE9-0002tB-2r for guile-devel@m.gmane.org; Sun, 18 Dec 2011 22:25:01 +0100 Original-Received: from localhost ([::1]:46526 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcOE8-0007ME-BY for guile-devel@m.gmane.org; Sun, 18 Dec 2011 16:25:00 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:35958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcOE5-0007LH-AI for guile-devel@gnu.org; Sun, 18 Dec 2011 16:24:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RcOE4-0005oQ-37 for guile-devel@gnu.org; Sun, 18 Dec 2011 16:24:57 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:56028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcOE2-0005ns-Ep; Sun, 18 Dec 2011 16:24:54 -0500 Original-Received: by iacb35 with SMTP id b35so6717804iac.0 for ; Sun, 18 Dec 2011 13:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JkKz5XUygKFcbD4xSDFKqjp6dmIHkkyxybMhkLwmg4k=; b=QwO0n2KE9FtmUqBfmkhKb0VI/Q7LGcIUnXKlkqjrlc/0mHEq4wGreCBvpAC6EvrNn1 YokP4N2bwidEU8SmzEYMq1zum7dIottrwcgPgEQtz0aIGdazwCpo13Quo5PV/TSdMg+u wUJSDHdLiEMbnnlp1i/hbwy+nmOxSM8SHPMCc= Original-Received: by 10.50.194.197 with SMTP id hy5mr20688632igc.84.1324243493590; Sun, 18 Dec 2011 13:24:53 -0800 (PST) Original-Received: by 10.42.217.6 with HTTP; Sun, 18 Dec 2011 13:24:53 -0800 (PST) In-Reply-To: <871us1x36x.fsf@fencepost.gnu.org> X-Google-Sender-Auth: E57hZ8bWlCTRtuhz-ias64OG8I0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 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:13158 Archived-At: Hello, >> 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? Let me explain what I mean more. Here is a code example: (let ((x 3)) (let ((x (* x 5))) (the-environment))) At the point of the-environment, there is one Scheme variable around, 'x', and its value is 15. The old value of x is shadowed by the new one. But psyntax works by assigning each of these x values a gensym, and they get different gensyms. So in theory, you could access the outer value of x (x = 3) if you had a handle on the right gensym. Supporting this seems weird to me, because I view psyntax as an implementation detail of Guile, and not something that should affect programmers. I also think that not supporting it is fine because if you want to be able to access both values, you can always give your variables different names. So this isn't giving you more power, but just a weird way to access it. > 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? I do not know enough to respond to the rest of your email. Noah