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: Anything better for delayed lexical evaluation than (lambda () ...)? Date: Tue, 13 Dec 2011 14:56:50 +0100 Organization: Organization?!? Message-ID: <87fwgolgm5.fsf@fencepost.gnu.org> References: <87liqtpsl9.fsf@fencepost.gnu.org> <874nxdwkbi.fsf@rapitore.luna> <87d3bvfo5d.fsf@fencepost.gnu.org> <871usaicvi.fsf@netris.org> <87mxaycmlx.fsf@fencepost.gnu.org> <87wra1hcek.fsf@netris.org> <87mxaxihnw.fsf@pobox.com> <87obvclu92.fsf@fencepost.gnu.org> <87aa6wbp0w.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1323784652 24623 80.91.229.12 (13 Dec 2011 13:57:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Dec 2011 13:57:32 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Dec 13 14:57:28 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 1RaSrI-0001M9-Jf for guile-devel@m.gmane.org; Tue, 13 Dec 2011 14:57:28 +0100 Original-Received: from localhost ([::1]:33669 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaSrI-0006mz-4U for guile-devel@m.gmane.org; Tue, 13 Dec 2011 08:57:28 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:55616) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaSr9-0006me-LE for guile-devel@gnu.org; Tue, 13 Dec 2011 08:57:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RaSr3-0004RY-Gu for guile-devel@gnu.org; Tue, 13 Dec 2011 08:57:19 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:34648) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaSr3-0004RO-8G for guile-devel@gnu.org; Tue, 13 Dec 2011 08:57:13 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RaSqz-0001F4-Io for guile-devel@gnu.org; Tue, 13 Dec 2011 14:57:09 +0100 Original-Received: from p508e9a39.dip.t-dialin.net ([80.142.154.57]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Dec 2011 14:57:09 +0100 Original-Received: from dak by p508e9a39.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Dec 2011 14:57:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 91 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508e9a39.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:D1/PYLRuw7uELmrLtziS3ojjrL0= 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:13054 Archived-At: Andy Wingo writes: > On Tue 13 Dec 2011 10:02, David Kastrup writes: > >> Lilypond's input language is not "David's current strategy". > > I was referring to your implementation strategy. It's not a strategy. Merely the least painful way to do things at a given point of time. The given point of time is that we need to cater for both Guile v1 and v2. > Mark describes another implementation strategy. > >> It does not help because it requires _advance_ knowledge of when you are >> going to want to fish for environments. You can call Lilypond's >> #{ ... #} construct in the normal REPL. You can call it in any function >> definition. It is pervasive. > > I was suggesting to evaluate all lilypond "scheme" code with the > lilypond "scheme" interpreter. Which means exactly that we can't use the repl anymore, and likely also not the Guile debugger. And get worse performance than with Guile v1. > I still think making your #{}# parser expand to lexically-scoped > Scheme is the best option. If using Scheme as one humongous block is the best (and pretty much only) option, Guile is no longer an extension language but a platform. And that means letting down the admittedly few people who bought into Guile's previous agenda. In any case, I don't see what is supposed to make Guile v2 conceptually distinct from any old Scheme interpreter if its closures are closed and shut. > Another option is to use the reflective facilities to implement a form > of procedure-environment. If you compile your Scheme procedures, with > partial evaluation disabled, you should be able to use > program-bindings to get this information. program-bindings does not appear present in Guile 1.8, so that's shelved at the current point of time. And the documentation in the manual about "Compiled Procedures" states Compiled procedures, also known as programs, respond all procedures that operate on procedures. In addition, there are a few more accessors for low-level details on programs. which likely could be phrased a bit more clearly if one wanted to find out how to make use of it. It then goes on to state: — Scheme Procedure: program-bindings program — Scheme Procedure: make-binding name boxed? index start end — Scheme Procedure: binding:name binding — Scheme Procedure: binding:boxed? binding — Scheme Procedure: binding:index binding — Scheme Procedure: binding:start binding — Scheme Procedure: binding:end binding Bindings annotations for programs, along with their accessors. Bindings declare names and liveness extents for block-local variables. The best way to see what these are is to play around with them at a REPL. See VM Concepts, for more information. Sorry, but "try out and see what it does" is not exactly a guarantee for and/or a definition of a stable API. I was not all that surprised to find that the chapter "VM Concepts" does indeed contain more information, unfortunately information that is not in any obvious way related to program-bindings. With that kind of documentation, few people will actually be using these functions and as a result you will likely not feel any compulsion to keep those around, either. > I wonder if we could provide some sort of current-bindings syntactic > form, also. It would require psyntax hooks, but it could work. I can't help the impression that a dependable and documented long-term strategy and corresponding commitment would at the current point of time be more important than brain-storming about short-lived hacks. The distinguishing feature for Lisp-like systems is the degree to which it is self-descriptive and "live". _That_ (and certainly not its syntax or performance) is what has made this language family the prime platform for AI applications. -- David Kastrup