From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Barzilay Newsgroups: gmane.lisp.guile.devel Subject: Re: Syntax Parameters documentation for guile Date: Sat, 31 Dec 2011 02:44:53 -0500 Message-ID: <20222.48501.219043.125940@winooski.ccs.neu.edu> References: <87pqff8f5g.fsf@Kagami.home> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1325317504 25523 80.91.229.12 (31 Dec 2011 07:45:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 31 Dec 2011 07:45:04 +0000 (UTC) Cc: Guile Mailing List To: Ian Price Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Dec 31 08:45:00 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 1Rgtch-000766-IH for guile-devel@m.gmane.org; Sat, 31 Dec 2011 08:44:59 +0100 Original-Received: from localhost ([::1]:56291 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rgtcg-0004iL-H2 for guile-devel@m.gmane.org; Sat, 31 Dec 2011 02:44:58 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:60182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rgtce-0004iG-58 for guile-devel@gnu.org; Sat, 31 Dec 2011 02:44:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rgtcc-0004Gf-Gd for guile-devel@gnu.org; Sat, 31 Dec 2011 02:44:55 -0500 Original-Received: from winooski.ccs.neu.edu ([129.10.115.117]:46027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rgtcc-0004Gb-CW for guile-devel@gnu.org; Sat, 31 Dec 2011 02:44:54 -0500 Original-Received: from winooski.ccs.neu.edu (localhost.localdomain [127.0.0.1]) by winooski.ccs.neu.edu (8.14.4/8.14.4) with ESMTP id pBV7irOA020378; Sat, 31 Dec 2011 02:44:53 -0500 Original-Received: (from eli@localhost) by winooski.ccs.neu.edu (8.14.4/8.14.4/Submit) id pBV7irwH020372; Sat, 31 Dec 2011 02:44:53 -0500 In-Reply-To: <87pqff8f5g.fsf@Kagami.home> X-Mailer: VM 8.2.0a under 23.2.1 (x86_64-redhat-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 129.10.115.117 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:13224 Archived-At: More than a week ago, Ian Price wrote: > > Eli, > I'd especially appreciate it if you could clear up any misconceptions I > may have, or may be unintentionally imparting on others. (And that I'm kind of on the list I can reply...) > * Syntax Parameters > > Syntax parameters[fn:1] are a mechanism for rebinding a macro > definition within the dynamic extent of a macro expansion. It > provides a convenient solution to one of the most common types of > unhygienic macro: those that introduce a special binding each time I'd explicitly say "unhygienic" here rather than "special". > the macro is used. Examples include an 'if' form that binds the > result of the test to an 'it' binding, or class macros that > introduce a special 'self' binding. The `abort' example is also popular, probably even more than `it'. I think that there are practical uses of that (eg, a function with a `return' keyword), whereas anaphoric conditionals are more of an academic exercise that I don't think gets used in practice (at least in Schemes). [As a sidenote, when I worked on that paper I've asked our local Perl guru about the problem of shadowing the implicit `it' in Perl -- he said that in practice it's considered bad style to use it in perl code, and referred me to some book that talks about the pitfalls of using it... I found it amusing that this perl-ism has become such a popular example for unhygienic macros where perl hackers actually try to avoid it.] > With syntax parameters, instead of introducing the binding > unhygienically each time, we instead create one binding for the > keyword, which we can then adjust later when we want the keyword to > have a different meaning. As no new bindings are introduced hygiene > is preserved. This is similar to the dynamic binding mechanisms we > have at run-time like parameters[fn:2] or fluids[fn:3]. An important note to add here is that there is no "dynamic scope" in the usual sense here -- it's rather a dynamic scope during macro expansion, and for macro-bound identifiers. The resulting expanded code is of course as lexical as always. (We've had some discussions at #scheme where this was a confusing point.) > ** define-syntax-parameter keyword transformer [syntax] > Binds keyword to the value obtained by evaluating transformer as a > syntax-parameter. The keyword is bound to the value of the `transformer' expression. (Evaluated at the syntax level, in Racket's case, I don't know if Guile has separate phases yet...) It's not evaluated as a syntax parameter, just like parameters. > The transformer provides the default expansion for the syntax > parameter, and in the absence of syntax-parameterize, is > functionally equivalent to define-syntax. A good note to add here is that it is usually bound to a transformer that throws a syntax error like "`foo' must be used inside a `bar'". It immediately clarifies the use of syntax parameters in the common case. > ** syntax-parameterize ((keyword transformer) ...) exp ... [syntax] > (note, each keyword must be bound to a syntax-parameter > > Adjusts each of the keywords to use the value obtained by evaluating > their respective transformer, in the expansion of the exp forms. It > differs from let-syntax, in that the binding is not shadowed, but > adjusted, and so uses of the keyword in the expansion of exp forms > use the new transformers. A possibly useful analogy is with `fluid-let' which doesn't create new bindings, but rather `set!'s them. But IMO `fluid-let' should die, so using parameters is a better example... -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life!