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 04:38:53 -0500 Message-ID: <87pnv6iss7.fsf@netris.org> References: <875zwzmq4n.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 1542274671 28334 195.159.176.226 (15 Nov 2018 09:37:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Nov 2018 09:37:51 +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 10:37:46 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 1gNE5q-0007GF-DO for guile-devel@m.gmane.org; Thu, 15 Nov 2018 10:37:46 +0100 Original-Received: from localhost ([::1]:37637 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNE7w-0006Ow-Qf for guile-devel@m.gmane.org; Thu, 15 Nov 2018 04:39:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNE7n-0006Oq-C6 for guile-devel@gnu.org; Thu, 15 Nov 2018 04:39:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gNE7Z-0002AB-U9 for guile-devel@gnu.org; Thu, 15 Nov 2018 04:39:39 -0500 Original-Received: from world.peace.net ([64.112.178.59]:35454) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gNE7Z-00029j-HL for guile-devel@gnu.org; Thu, 15 Nov 2018 04:39:33 -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 1gNE7Y-000543-CF; Thu, 15 Nov 2018 04:39:32 -0500 In-Reply-To: ("Marc \=\?utf-8\?Q\?Nieper-Wi\=C3\=9Fkirchen\=22's\?\= message of "Wed, 14 Nov 2018 21:27:17 +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:19738 Archived-At: Hi Marc, Marc Nieper-Wi=C3=9Fkirchen writes: > Am Mi., 14. Nov. 2018 um 20:11 Uhr schrieb Mark H Weaver : > > > The `ellipsis?' procedure in psyntax.ss does exactly this, but it > > isn't available to user code. Re-implementing it is not possible > > without accessing internal details like the special identifier #{ > > $sc-ellipsis }# and without resorting to hacks. > > Surprisingly, it actually _is_ possible to do it portably in any > R[567]RS Scheme. See 'match-check-ellipsis' near the end of > modules/ice-9/match.upstream.scm. > > This is why I wrote "without resorting to hacks". :-) Heh, fair enough :) > > Thus, I would like to ask to add `ellipsis?' to the list of procedures > > exported by Guile (like `identifier?` or `bound-identifier=3D?` already > > are). > > I'll need to think about how this could be exposed in the API. It's not > as simple as exporting that procedure. The 'ellipsis?' procedure is not > able to answer the question by looking only at the syntax object; it > also needs the macro-expansion environment 'r', which you do not have. > 'identifier?' and 'bound-identifier=3D?' only need the syntax objects. > > I think I understand (please correct me if I am wrong): If we want to > check whether `e' is the current ellipsis, we cannot simply look up > the binding of `(datum->syntax e '$sc-expand)' because the wrap of `e' > may be different than the wrap of the, say, `syntax-case' or `syntax' > form in which `e' appears. That's not what I meant, but anyway I've since discovered that the problem I raised has an easy solution. It turns out that Andy Wingo added a fluid variable 'transformer-environment', private to psyntax.scm, that allows us to retrieve the needed environment 'r' from the dynamic environment. > 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'. 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. If you think of it this way, it should be clear why you can't tell by looking at an identifier whether it is the current ellipsis in a given lexical environment. The information simply isn't there. Anyway, as I wrote above, the good news is that we can get 'r' from the dynamic environment. I have a draft patch to add a unary predicate to (system syntax), but I'd like to work on it a bit more before posting it. Regards, Mark