From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Feature request: Expose `ellipsis?' from psyntax.ss Date: Thu, 15 Nov 2018 05:59:06 -0500 Message-ID: <87k1leip2i.fsf@netris.org> References: <875zwzmq4n.fsf@netris.org> <87pnv6iss7.fsf@netris.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1542279499 9087 195.159.176.226 (15 Nov 2018 10:58:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Nov 2018 10:58:19 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: guile-devel@gnu.org To: Marc =?utf-8?Q?Nieper-Wi=C3=9Fkirchen?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Nov 15 11:58:14 2018 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNFLg-0002Cx-KR for guile-devel@m.gmane.org; Thu, 15 Nov 2018 11:58:12 +0100 Original-Received: from localhost ([::1]:38133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNFNn-0005mY-2o for guile-devel@m.gmane.org; Thu, 15 Nov 2018 06:00:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35894) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNFNM-0005lc-0h for guile-devel@gnu.org; Thu, 15 Nov 2018 05:59:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gNFNJ-000314-1z for guile-devel@gnu.org; Thu, 15 Nov 2018 05:59:55 -0500 Original-Received: from world.peace.net ([64.112.178.59]:36236) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gNFNI-0002uG-TX for guile-devel@gnu.org; Thu, 15 Nov 2018 05:59:52 -0500 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gNFNC-0005PW-58; Thu, 15 Nov 2018 05:59:46 -0500 In-Reply-To: ("Marc \=\?utf-8\?Q\?Nieper-Wi\=C3\=9Fkirchen\=22's\?\= message of "Thu, 15 Nov 2018 11:03:46 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 64.112.178.59 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.lisp.guile.devel:19740 Archived-At: Hi Marc, Marc Nieper-Wi=C3=9Fkirchen writes: > > So what we actually need is a procedure of > > two arguments: `(ellipsis? e ctx)' returns `#t' if the identifier `e' > > is the current ellipsis in the lexical environment of the identifier > > `ctx'. > > Hmm. I don't actually see a need for the second argument, do you? I > can't think of a case where I'd want to 'e' to be different from 'ctx'. > > Let's assume we are writing a macro that reimplements syntax (or some > variation thereof) and which has to check whether identifiers are > ellipses. For example, the following could be given: > > (with-ellipsis e > (my-syntax a e) >=20=20 > Now, this could be a result of a macro expansion and e could carry > different marks than with-syntax or my-syntax. This is why I have been > thinking that one also needs the lexical context of my-syntax and not > only the context of e. I don't see what problem would be caused by 'e' carrying different marks than 'my-syntax'. As far as I can tell, in the end, the two instances of 'e' above will effectively be compared to one another using 'bound-identifier=3D?'. They must have the same name and the same marks to match. The marks on 'my-syntax' are irrelevant here. Operationally, when (with-ellipsis e (my-syntax a e)) is expanded, 'e' will be added to the macro expansion environment as the innermost binding of the ellipsis identifier, and then (my-syntax a e) will be expanded within that new expansion environment. That is the expansion environment that will be consulted by the 'ellipsis-identifier?' predicate to find the current ellipsis identifier, which is compared with its argument (after stripping its anti-mark) using 'bound-identifier=3D?'. > The issue I raised has to do with the fact that syntax-objects do not > contain their lexical environments. The 'wrap' of a syntax-object > essentially only contains a set of deferred substitutions to be applied > to the identifiers within the syntax object, if they end up outside of a > quoted datum in the expanded code. The wrap is primarily an efficiency > hack, but also enables the implementation of 'datum->syntax'. > > If we eliminated the efficiency hack, and also 'datum->syntax', we could > implement identifiers more simply as a record containing two symbols: > the original symbol, and the symbol after all substitutions have been > applied. Identifiers found within quoted datums would be interpreted as > their original symbols, and identifiers found anywhere else would be > interpreted as the symbols with the substitutions applied. > > Thanks for the explanation. I have been toying with my own > implementation of the syntax-case system. In my implementation the > (shared) lexical environments are part of the wraps (so the > identifiers are in some way self-contained). Interesting. Are locally-bound macro transformers included in those lexical environments? If so, how do you implement 'letrec-syntax'? > Will ellipsis? also work outside of macros? Say, what would be the > result of the following (run-time) code? > > (with-syntax e > (ellipsis? #'e) No, this is an error. Like 'syntax-local-binding', the 'ellipsis-identifier?' predicate must be called within the dynamic extent of a macro transformer call by the macro expander. > P.S.: By the way, the module (system syntax) and in particular the > procedure syntax-local-binding has already helped me a lot because I > needed to attach extra information to symbols and Guile doesn't (yet) > support Chez's define-property (well, this would be another feature > request). Hmm. Can you tell me more specifically how you are using 'syntax-local-binding' to accomplish this? As the Guile manual warns, those interfaces are subject to change in future versions of Guile, and therefore it is best to avoid them where possible. Regards, Mark