From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel Subject: Re: syntax-local-value patch for discussion Date: Mon, 23 Jan 2012 17:06:09 +0100 Message-ID: References: <87fwfq6m5x.fsf@netris.org> <87pqeapu4o.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0015174c16607159d704b73435a5 X-Trace: dough.gmane.org 1327334814 16776 80.91.229.12 (23 Jan 2012 16:06:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2012 16:06:54 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jan 23 17:06:50 2012 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 1RpMPw-0003dz-S3 for guile-devel@m.gmane.org; Mon, 23 Jan 2012 17:06:49 +0100 Original-Received: from localhost ([::1]:60964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpMPw-0000bm-CY for guile-devel@m.gmane.org; Mon, 23 Jan 2012 11:06:48 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:60902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpMPo-0000YZ-Dq for guile-devel@gnu.org; Mon, 23 Jan 2012 11:06:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpMPf-0007IX-3L for guile-devel@gnu.org; Mon, 23 Jan 2012 11:06:40 -0500 Original-Received: from mail-ey0-f169.google.com ([209.85.215.169]:48173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpMPe-0007Fk-NC for guile-devel@gnu.org; Mon, 23 Jan 2012 11:06:31 -0500 Original-Received: by eaai11 with SMTP id i11so521349eaa.0 for ; Mon, 23 Jan 2012 08:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8aHfJRC61/vb507j9CUqBIHSb7Wenipn/OdnKFWn/R8=; b=uVocsqN9wdtWlkRJkgXpcgA4DHoPkX0xmHqIjIiuWU7DfgnxsrazG6XbCvxKbYXy0m I625rCdFsvwUZfWehqwtAJgODL54AebHpHVDFT8VcSpIDNY0UuMSqeDfklAQIZX0uRCd 5yQz2aVr2h2b+BKZ9tGnMNXNpk6ZT838nwM00= Original-Received: by 10.213.32.202 with SMTP id e10mr1684615ebd.98.1327334769645; Mon, 23 Jan 2012 08:06:09 -0800 (PST) Original-Received: by 10.213.7.6 with HTTP; Mon, 23 Jan 2012 08:06:09 -0800 (PST) In-Reply-To: <87pqeapu4o.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.215.169 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:13645 Archived-At: --0015174c16607159d704b73435a5 Content-Type: text/plain; charset=ISO-8859-1 Ok, here is a discussoin using code in syntax-parse. Let's start with the defintion of a syntax-class, str in the macro package syntax-parse: (define-syntax-class str #:attributes () #:opaque #:commit #:description "string" (pattern (~and x (~fail #:unless (string? (syntax-e #'x)))))) So the and patterns first match x and then on the same element match a ~fail that fails if the supplied code (string? (syntax-e #'x)) is false. The headake for me is that #'(string? (syntax-e #'x)) is stored in a struct and hence does not get wrapped correctly e.g. after the packaging of this code in a struct, say S we will then issue something like the following code in the expansion of the first match #'(with-syntax ((x stx)) (parse stx S)) and when parse is ready to unpack S we could have S = #(syntax-object # wrap-part hygiene) Now I basically solve this problem by constructing a = (vector 'syntax-object (vector-ref (struct-s-code (syntax->datum S)) 1) (un-mark wrap-part) hygiene) crossing the fingers that the "code" will be nonatomic and then the expander will use it like, (with-syntax ((code a)) #'( .... code)) This is the story. I do not want to rest here because this solution is not resistant to bitrot and depends on internals that I do not want to touch. The solution would be to have an interface in guile that allows to write, (with-syntax ((code (syntax-embedd (struct-s-code (syntax->datum S)) S))) (.... code ...)) e.g. (syntax-embedd exp env-stx) = embedds exp in the syntax env-stx I'm much more fine with dropping env-stx and replace that with the equivalent syntax environment at the macro call I Hope that things are less foggy now! Regards Stefan On Mon, Jan 23, 2012 at 11:53 AM, Andy Wingo wrote: > Hi Stefan, > > On Thu 19 Jan 2012 10:50, Stefan Israelsson Tampe > writes: > > > Working on porting syntax-parse is a learning experience and I know > > understand how it uses syntax-local-value as a way to lookup a syntax > > object by joining the wraps together with the total wrap at the macro > > call. > > syntax-local-binding just uses the wrap from the id that you give it, > without joining it to the macro expansion environment's wrap. > > > I would like to have a syntax-join function that takes two syntax > > objects and join them correctly and robustly in the pressense of > > eventual marks or not. > > Why would you want to do something like this? > > You might try writing the documentation of the function first; it would > clarify the conversation. > > Regards, > > Andy > -- > http://wingolog.org/ > --0015174c16607159d704b73435a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, here is a discussoin using code in syntax-parse.

Let's start= with the defintion of a syntax-class, str in the macro package syntax-pars= e:
(define-syntax-class str #:attributes () #:opaque #:commit
=A0 #:d= escription "string"
=A0 (pattern (~and x (~fail #:unless (string? (syntax-e #'x))))))
So the and patterns first match x and then on the same element match a ~f= ail
that fails if the supplied code (string? (syntax-e #'x)) is fal= se.

The headake for me is that #'(string? (syntax-e #'x)) is stor= ed in a struct and hence
does not get wrapped correctly e.g. after the p= ackaging of this code in a struct, say S
we will then issue something li= ke the following code in the expansion of the first match

#'(with-syntax ((x=A0 stx))=A0 (parse stx S))

and when parse= is ready to unpack S we could have

S =3D #(syntax-object #<struc= t-s> wrap-part hygiene)

Now I basically solve this problem by con= structing
a =3D (vector 'syntax-object (vector-ref (struct-s-code (syntax->dat= um S)) 1) (un-mark wrap-part) hygiene)
crossing the fingers that the &qu= ot;code" will be nonatomic and then the expander will use it like,

(with-syntax ((code a)) #'( .... code))

This is the story. I= do not want to rest here because this solution is not resistant to bitrot = and depends on internals that I do not want to touch. The solution would be= to have an interface in guile that allows to write,

(with-syntax ((code (syntax-embedd (struct-s-code (syntax->datum S))= S))) (.... code ...))

e.g.

(syntax-embedd exp env-stx) =3D e= mbedds exp in the syntax env-stx

I'm much more fine with droppin= g env-stx and replace that with the equivalent syntax environment at the ma= cro call

I Hope that things are less foggy now!

Regards
Stefan

=


On Mon, Jan 23, 2012 at 11:53 AM, An= dy Wingo <wingo@pob= ox.com> wrote:
Hi Stefan,

On Thu 19 Jan 2012 10:50, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:

> Working on porting syntax-parse is a learning experience and I know > understand how it uses syntax-local-value as a way to lookup a syntax<= br> > object by joining the wraps together with the total wrap at the macro<= br> > call.

syntax-local-binding just uses the wrap from the id that you give it,=
without joining it to the macro expansion environment's wrap.

> I would like to have a syntax-join function that takes two syntax
> objects and join them correctly and robustly in the pressense of
> eventual marks or not.

Why would you want to do something like this?

You might try writing the documentation of the function first; it would
clarify the conversation.

Regards,

Andy
--
http://wingolog.org/=

--0015174c16607159d704b73435a5--