From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Maciek Godek" Newsgroups: gmane.lisp.guile.user Subject: Re: Me no understand scoping Date: Wed, 30 Jul 2008 21:24:02 +0200 Message-ID: References: <87r69ccaus.fsf@unknownlamer.org> <489074A9.1080508@wilsonjc.us> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1217446224 30541 80.91.229.12 (30 Jul 2008 19:30:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Jul 2008 19:30:24 +0000 (UTC) Cc: guile-user@gnu.org To: "Jon Wilson" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Jul 30 21:31:13 2008 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KOHOD-0000PU-E0 for guile-user@m.gmane.org; Wed, 30 Jul 2008 21:31:13 +0200 Original-Received: from localhost ([127.0.0.1]:46201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOHNI-0002BX-W7 for guile-user@m.gmane.org; Wed, 30 Jul 2008 15:30:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KOHNE-0002AD-2P for guile-user@gnu.org; Wed, 30 Jul 2008 15:30:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KOHND-000290-1l for guile-user@gnu.org; Wed, 30 Jul 2008 15:30:11 -0400 Original-Received: from [199.232.76.173] (port=36239 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOHNC-00028q-Nr for guile-user@gnu.org; Wed, 30 Jul 2008 15:30:10 -0400 Original-Received: from wf-out-1314.google.com ([209.85.200.175]:55138) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KOHNC-0007sz-EM for guile-user@gnu.org; Wed, 30 Jul 2008 15:30:10 -0400 Original-Received: by wf-out-1314.google.com with SMTP id 28so135781wfc.24 for ; Wed, 30 Jul 2008 12:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=cVWtDzXQTV23Y94Gd2XdqPNpnaKLK/p2reVO54RmERY=; b=xMV8WGtL0+sozGM4GavEp35jliO62txyq/0bwZFu3HFU5S+nynl0XwamVdtGhrhiix HPaKIDPDcyL5U9/8fLHLEma+dNTNKcbjfyRHrmGxJmGISKH0hhNVWSgqGJYxif4FOEOI qq3JJ3oQq3JIQWPRmnIQdgX9ffittx6NwY240= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pC+RFcRpKbaq2SnO3OHxwYAX+TURMJRKFtFqPSJOj6Oz72BNu952NDj1SlT/VpGy05 j0IMkZz7YREYbRbkcDXOdDDzpM5yC3tKSRtynX0uOdQDocmY4VOb70pBJMktonPCVE0D kuLSQfKy7ikR1wN2nRv1Nenz997WIvA1IfEiQ= Original-Received: by 10.142.12.14 with SMTP id 14mr2916528wfl.147.1217445843020; Wed, 30 Jul 2008 12:24:03 -0700 (PDT) Original-Received: by 10.142.141.17 with HTTP; Wed, 30 Jul 2008 12:24:02 -0700 (PDT) In-Reply-To: <489074A9.1080508@wilsonjc.us> Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6707 Archived-At: >> as for eval, it will always be there (in RnRS) > > EVAL has not been in every report. R4RS did not specify EVAL, nor did R3RS, > RRRS, RRS. The fact that R5RS does only proves the fact that they should have :) By the way I have a question (regarding not using eval). I want to pass the contents of a list to a function that accepts the so-called "rest" args. (let ((l '(1 2 3 4 5))) (let ((operation (append '(+) l))) (primitive-eval operation) ) ) How to achieve this effect without using eval? (I've tried (+ . l) but it didn't work out) >> besides I don't imagine not messing with lexical >> environments :) The bad thing is that scopes aren't >> explicitly definable and the report doesn't say >> much about their properties. I don't know how >> about practical performance, but I'd find it best >> if they were implemented as (implicit) hash tables >> that could be bound to variables and passed as >> arguments. I think that they could perform >> equally good as fixed arrays for memoized >> procedures. > > The view of the scheme community as a whole is that first class lexical > environments are irreconcilable with the need to compile (optimize) code. Certainly there's a faction that thinks differently :] > In many cases, once you have done some variety of compilation, a lot of the > lexical environments you think you ought to have will have been optimized > away; conversely, preserving these environments will prevent entire classes > of compilation. Unless some limitations are to be imposed on compiled closures (and some control over optimization is given to the programmer) I see no problem with that. > I am of the suspicion that in most cases, the environment would never be > reified, the compiler could prove this, and optimization could proceed as > desired. However, I would still agree with Clinton that you should avoid > messing with environments, first class or otherwise, whenever possible. > When you must, you should quarantine it: use it in a very limited part of > your code, where you wrap it in a more mundane abstraction, then use that > abstraction elsewhere. CALL/CC should be treated the same way usually. Yeah, I always write additional layers so the code corresponds to the way I think. (Everybody does, don't they?) > Broadening the topic a bit, it seems that first class envs and macros (and > maybe not macros!) are all that would be needed to define a module system in > scheme, rather than building it into the interpreter. Then the module > system could be put in a file which any r5rs+envs (or whatever standard you > like) scheme could LOAD (most likely implicitly at startup) without > modification to the interpreter itself. It might even be the case that > DEFMACROs and reified environments would be sufficient to make low-level > hygienic macros a library too (but I'm no macrologist, for sure). You would > still have to deal with the compilation issues, but as I said, my gut > feeling is that these are solvable. Such a pretty vision you have :) ("and no religion too..." :P) The thing is that this would really make *everything* simpler. (or maybe it's just another collective hallucination)