From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Matt Wette Newsgroups: gmane.lisp.guile.user Subject: Re: problems with syntax-case and with-syntax Date: Wed, 20 Sep 2017 05:50:19 -0700 Message-ID: <89D4027A-4E40-4CC0-9C14-4C4974E9AF96@gmail.com> References: <87lgm4il3u.fsf@netris.org> <87efrwiief.fsf@netris.org> <33BDE2DC-09AB-4DBF-AD42-9929CE936F79@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1505915467 23241 195.159.176.226 (20 Sep 2017 13:51:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 20 Sep 2017 13:51:07 +0000 (UTC) Cc: Guile User To: Mark H Weaver Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Sep 20 15:50:55 2017 Return-path: Envelope-to: guile-user@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 1dufOx-0005Jr-87 for guile-user@m.gmane.org; Wed, 20 Sep 2017 15:50:55 +0200 Original-Received: from localhost ([::1]:48201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dufP3-0005in-0T for guile-user@m.gmane.org; Wed, 20 Sep 2017 09:51:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1duev4-0005hz-3W for guile-user@gnu.org; Wed, 20 Sep 2017 09:21:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1duety-00030L-Vl for guile-user@gnu.org; Wed, 20 Sep 2017 09:20:01 -0400 Original-Received: from mail-pf0-x22d.google.com ([2607:f8b0:400e:c00::22d]:47634) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1duety-0002wM-Qg for guile-user@gnu.org; Wed, 20 Sep 2017 09:18:54 -0400 Original-Received: by mail-pf0-x22d.google.com with SMTP id u12so1520740pfl.4 for ; Wed, 20 Sep 2017 06:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1qgWsNtv+0lGAZ3pshMbEzBOVIYm03ZZ9tgN3Ykhdj0=; b=QhOHRbScDcHmmZFUU7hcEL7R9FGXeTB7sUGPdH8f89D06ynbQ/yW/jvpwrIi/Ykbua EHaLDulBT4bQm0EISuE1TmnSWaBA0zIgUREkAGZ75q8oYSgacp0pKtDmESd3bmC7nNK7 X1OjN8NfrwwBUmYGTUV6XHv9gpyInbPlBWDgKp8SWEOr6JJEqVvhWqmy/iTAuVg5Kf/F 0PVBwahP8Z8jfGdEoOBgPcit62g9c48VdN3KU7fQ4qbFSSr/OlEvsNI5j1d4RtbIja4Y 9Wy055VRMF5sRIAD/I5CfrzQg+aQpVFzolmM24s28Oxi5zNwoNBe8ODW1tIFD1Yja87L AC6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1qgWsNtv+0lGAZ3pshMbEzBOVIYm03ZZ9tgN3Ykhdj0=; b=L1YwV3nraduFVMp7U6dIPALF1hfIIpouQs0W5k68JCtkOlqnEWcT15yMhY0VKEvU4h H0X7jzEZ3eYn5kbFF6ndRqIBbf+Cy8KmDboViLgPvEHrdhBKLIIxAA/G7sOrG12v7Xep oPIXz/QVAY69ZLpfcG247+ZgdICtTcr0Dg+Z54J+5F3JeLJxTBkHfHMM33cDRyhgcYTe fVDn/zHBFAOuB8m/G6ERNKprx7aZNy3qRdyxG8Nss8tdxzeLliCpdnc8AIKsBvzjMcU3 0A/w2/GPn/V7bWiE/nAQ2ez5IpCSj4gOlDrrT4waEupu8LfkbfeVZGnon4w0WNMuBuXK +qTA== X-Gm-Message-State: AHPjjUh2l8mqznL8XR4emQfUBsV3Wc7YpUHphkE0ejYkaCQR2/ch5QsH WlVxCtsbYdvinIQO0AZWfkw= X-Google-Smtp-Source: AOwi7QD9GHyZeZLibqFqbVCTHir/nb3A+4lJDmUeF/MVJBQh2rokW0rug+WgqoOb2lKj97ld+KMe5A== X-Received: by 10.101.76.207 with SMTP id n15mr2153813pgt.120.1505911821668; Wed, 20 Sep 2017 05:50:21 -0700 (PDT) Original-Received: from nautilus.championbroadband.com (216-165-229-229.championbroadband.com. [216.165.229.229]) by smtp.gmail.com with ESMTPSA id x9sm8047384pfk.40.2017.09.20.05.50.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 05:50:21 -0700 (PDT) In-Reply-To: <33BDE2DC-09AB-4DBF-AD42-9929CE936F79@gmail.com> X-Mailer: Apple Mail (2.3273) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400e:c00::22d X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:14176 Archived-At: > On Sep 18, 2017, at 6:16 AM, Matt Wette wrote: >=20 >>=20 >> On Aug 27, 2017, at 6:35 PM, Mark H Weaver wrote: >>=20 >> Mark H Weaver writes: >>=20 >>> The problem is that in Guile 2.2, whenever (define ...) is = found in >>> the expanded code, where was introduced by a macro (i.e. not = passed >>> as an explicit argument to the macro), Guile will rewrite the = into >>> a new name based on the hash of the entire definition form. >>=20 >> I forgot to mention that only top-level definitions are munged in = this >> way. >>=20 >> Also, my parenthetical definition of what it means to be "introduced = by >> a macro" lacked precision. To avoid being "introduced by a = macro", >> it's not enough for to have been passed an argument to the macro >> that generated the definition. If that were the case, you could work >> around this by adding an additional layer of macros, where the upper >> layer generated and passed it down to the lower layer which = would >> generate the definition. >>=20 >> To avoid being considered "introduced by a macro", must >> ultimately occur verbatim in the source code outside of any macro >> template. >=20 > I have read through the posts, and the Guile 2.2 ref manual. The = explanations > are not quite complete in my mind. If all top-level id's introduced = by macros > were munged, then it would break a lot of existing code. See, for = example, > the `define-structure' example in "The Scheme Programming Language", = 4th ed. > It seems identifiers introduced by datum->syntax are preserved, as = long=20 > as they are not redefined. Is that correct? >=20 > In my case, I was redefining by architecture (or convention). I was = generating=20 > "wrap-" + in a macro that called a another macro that = made the same=20 > definition. Is it bad form to assume an convention like this? >=20 > Off to do more reading on this: Dybvig's paper on syntax-case and I = have the=20 > book too. and R6RS ... I have been convinced that introducing top-level definitions is bad = form, so I will=20 be removing datum->syntax calls but stuffing some procedures into the = associated=20 struct, I think. So instead of (define-fh-type foo_t) ... (unwrap-foo_t obj) I will use (define-fh-type foo_t foo_t? make-foo_t) ... (fh-unwrap foo_t obj) Matt