From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Newsgroups: gmane.lisp.guile.devel Subject: Re: Feature request: Expose `ellipsis?' from psyntax.ss Date: Thu, 15 Nov 2018 11:03:46 +0100 Message-ID: References: <875zwzmq4n.fsf@netris.org> <87pnv6iss7.fsf@netris.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004a9ed2057ab12ba7" X-Trace: blaine.gmane.org 1542276132 16268 195.159.176.226 (15 Nov 2018 10:02:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Nov 2018 10:02:12 +0000 (UTC) Cc: guile-devel@gnu.org To: mhw@netris.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Nov 15 11:02:07 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 1gNETP-00047B-Ku for guile-devel@m.gmane.org; Thu, 15 Nov 2018 11:02:07 +0100 Original-Received: from localhost ([::1]:37781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNEVW-0007pw-7y for guile-devel@m.gmane.org; Thu, 15 Nov 2018 05:04:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNEVI-0007kc-VF for guile-devel@gnu.org; Thu, 15 Nov 2018 05:04:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gNEVD-0000Qp-3a for guile-devel@gnu.org; Thu, 15 Nov 2018 05:04:04 -0500 Original-Received: from mail-pg1-f182.google.com ([209.85.215.182]:43927) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gNEVC-0000QF-RR for guile-devel@gnu.org; Thu, 15 Nov 2018 05:03:59 -0500 Original-Received: by mail-pg1-f182.google.com with SMTP id n10-v6so8779238pgv.10 for ; Thu, 15 Nov 2018 02:03:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=08e6V78TeUOx2AVkiKgzRUMpWgReATZK0jLOG1WDWDc=; b=EM9Cgn4ao6c0p3/gC+yrOfhdmjrpbsqONMe0QQVhz76Dsy6IiLrDebwDrNUmZzkEeG 3uLWxhoIpMj89HXZ3+OslfoCGNx8e2jeTkLNywUGdl6wLApJ0hwtaEn4RMYVb54SA9+Z xihlTm9kFVlJSsLm7KZHGeCy4Ascf2CNkHN0ZVv38maCwaCsrkQDH9tGBnXVSDPdfkib LCg4mh8NNFna1XkeD1vyq3Cuxq8XEx9dRB3MLr6qtuhxEwm5YrmNEIBHmDExHPRSfxvm yhKQ6TqBNo6pTxR7+GanNP3+n+25xhtYqM8ygDZB6rTAKzZOaJZdEU/XoE411Q9IUlC4 zRNQ== X-Gm-Message-State: AGRZ1gLrqo6xAllREVrl6er2LoTT3v8XdJZiNV+PIwcuCrjJotviI9Aw ZEXH4G5oiKlkRXakLYqOgQWRLPbBEQRFWWlUWxvcloXzEMo= X-Google-Smtp-Source: AJdET5eLlGcYVB/KtVpwve8WGOoCH9ZBkfiWC69vMw6fJQ1/WCtdREDcchDdBa5mkERRoQbqRh+AdNF38tOXFHJX63E= X-Received: by 2002:a63:6f0d:: with SMTP id k13mr5183622pgc.42.1542276237662; Thu, 15 Nov 2018 02:03:57 -0800 (PST) In-Reply-To: <87pnv6iss7.fsf@netris.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.215.182 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:19739 Archived-At: --0000000000004a9ed2057ab12ba7 Content-Type: text/plain; charset="UTF-8" Hi Mark, > > > 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) 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. 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). Anyway, as I wrote above, the good news is that we can get 'r' from the > dynamic environment. > Will ellipsis? also work outside of macros? Say, what would be the result of the following (run-time) code? (with-syntax e (ellipsis? #'e) > 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. > That's great news! Thanks! Best, Marc 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). --0000000000004a9ed2057ab12ba7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mark,

> So what we actually need is a procedure of
> two arguments: `(ellipsis?=C2=A0 e ctx)' returns `#t' if the i= dentifier `e'
> is the current ellipsis in the lexical environment of the identifier > `ctx'.

Hmm.=C2=A0 I don't actually see a need for the second argument, do you?= =C2=A0 I
can't think of a case where I'd want to 'e' to be different= from 'ctx'.

Let's assume w= e are writing a macro that reimplements syntax (or some variation thereof) = and which has to check whether identifiers are ellipses. For example, the f= ollowing could be given:

(with-ellipsis e
=C2=A0 (my-syntax a e)
=C2=A0
Now, this could be a re= sult of a macro expansion and e could carry different marks than with-synta= x or my-syntax. This is why I have been thinking that one also needs the le= xical context of my-syntax and not only the context of e.

The issue I raised has to do with the fac= t that syntax-objects do not
contain their lexical environments.=C2=A0 The 'wrap' of a syntax-ob= ject
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.=C2=A0 The wrap is primarily an efficienc= y
hack, but also enables the implementation of 'datum->syntax'.
If we eliminated the efficiency ha= ck, 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.=C2=A0 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 wit= h my own implementation of the syntax-case system. In my implementation the= (shared) lexical environments are part of the wraps (so the identifiers ar= e in some way self-contained).

Anyway, as I wrote above, the good news is that we can get &#= 39;r' from the
dynamic environment.

Will ellipsis? als= o work outside of macros? Say, what would be the result of the following (r= un-time) code?

(with-syntax e
=C2=A0 (el= lipsis? #'e)
=C2=A0
I hav= e 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.

That's great news! Thanks!
=C2=A0
Best,

Marc

P.S.: B= y the way, the module (system syntax) and in particular the procedure synta= x-local-binding has already helped me a lot because I needed to attach extr= a information to symbols and Guile doesn't (yet) support Chez's def= ine-property (well, this would be another feature request).
--0000000000004a9ed2057ab12ba7--