From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] psyntax: custom ellipses using 'with-ellipsis' or R7RS syntax-rules Date: Wed, 08 Jan 2014 15:10:41 -0500 Message-ID: <8761puxmim.fsf@netris.org> References: <87bo0del31.fsf@netris.org> <871u0i8zvx.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389211997 2465 80.91.229.3 (8 Jan 2014 20:13:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Jan 2014 20:13:17 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jan 08 21:13:21 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W0zV8-0001Ji-VN for guile-devel@m.gmane.org; Wed, 08 Jan 2014 21:13:19 +0100 Original-Received: from localhost ([::1]:48761 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0zV8-0007OL-5u for guile-devel@m.gmane.org; Wed, 08 Jan 2014 15:13:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0zUz-0007L2-R4 for guile-devel@gnu.org; Wed, 08 Jan 2014 15:13:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0zUr-0008Ok-Ga for guile-devel@gnu.org; Wed, 08 Jan 2014 15:13:09 -0500 Original-Received: from world.peace.net ([96.39.62.75]:41462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0zUr-0008O5-C6; Wed, 08 Jan 2014 15:13:01 -0500 Original-Received: from 209-6-197-194.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com ([209.6.197.194] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1W0zUY-0007sl-Sv; Wed, 08 Jan 2014 15:12:43 -0500 In-Reply-To: <871u0i8zvx.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 08 Jan 2014 12:41:06 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:16791 Archived-At: Hi Ludovic, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver skribis: > >> In the end, here's how this works: 'with-ellipsis' binds a special >> identifier named #{ $sc-ellipsis }# using a new 'ellipsis' binding type. >> The new ellipsis identifier is stored within the binding. In order to >> determine whether an identifier X is an ellipsis, the binding for >> #{ $sc-ellipsis }# is looked up in the lexical environment of X. If the >> binding is found and has binding-type 'ellipsis', then X is compared to >> the identifier stored in the binding using 'bound-id=3D?'. Otherwise, X >> is compared to '...' using 'free-id=3D?' as was done before. > > This looks nice! Thanks for providing the detailed reasoning, that=E2=80= =99s > insightful. > > Does something like this work: > > (define-syntax define-inline > (with-ellipsis --- > (syntax-rules () > ((_ (name parms ---) exp ---) > (define-syntax name > (syntax-rules () > ((_ args (--- ---)) > ((lambda (parms ---) exp ---) > args (--- ---))))))))) No, because as noted in the docs, the custom ellipsis does not propagate to the generated code. Therefore, given the above definition, (define-inline (foo a b c) (list a b c)) expands to: (define-syntax foo (syntax-rules () ((_ args ---) ((lambda (a b c) (list a b c)) args ---)))) However, '---' is not the ellipsis identifier for this generated macro, because the 'with-ellipsis' is not present in the generated code. Therefore, '---' is treated as a normal pattern variable by the generated macro. It is important that the custom ellipsis does not propagate to the generated code, so that we can use 'with-ellipsis' to implement R7RS 'syntax-rules', which allows a custom ellipsis as its first operand, before the literals list. In R7RS 'syntax-rules', the custom ellipsis does not propagate to generated code. A corrected version of your macro is the following: (define-syntax define-inline (with-ellipsis --- (syntax-rules () ((_ (name parms ---) exp ---) (define-syntax name (syntax-rules () ((_ args ...) ((lambda (parms ---) exp ---) args ...)))))))) Note that as currently implemented, the effect of 'with-ellipsis' also does not propagate into nested syntax definition forms such as 'let-syntax', 'letrec-syntax', and 'define-syntax'. We could go either way on this. I confess that I didn't make this decision intentionally. It was an accident of the current implementation. The reason is that transformer expressions are evaluated in a "macros only" environment, with all other bindings removed (see 'macros-only-env' in psyntax.scm). We could arrange to keep the ellipsis binding in that restricted environment as well, if desired. I don't think it matters much. What do you think? > Could you wrap lines to 80 columns in psyntax.scm? Ordinarily I try to keep lines to 80 columns, but psyntax.scm already has a great deal of code that violates that rule. Fixing that would be a rather large commit, and I'm not sure it would be an improvement. >> +@subsubsection Specifying a custom ellipsis identifier > > Should be =E2=80=9CSpecifying a Custom Ellipsis Identifier=E2=80=9D. > >> +@subsubsection Custom ellipsis identifiers for syntax-case macros > > Likewise. Okay. Thanks! Mark