From: Andy Wingo <wingo@pobox.com>
To: guile-devel <guile-devel@gnu.org>
Subject: pending branch: lexical-literals
Date: Fri, 29 Apr 2011 17:16:32 +0200 [thread overview]
Message-ID: <m3liytxf3j.fsf@unquote.localdomain> (raw)
Hi all,
I have a branch that fixes literal matching to actually compare toplevel
bindings, as the RNRS suggest, rather than simply assuming that a
literal that is not lexically bound can be compared symbolically.
(Recall that literals are things like `else' and `=>' in `cond'.)
I send this note because this change increases the coupling between a
macro's definition and the definition of the literals that it
references.
For example, in the past:
scheme@(guile-user)> (cond (else #t))
$1 = #t
Here the `else' is unbound both in the definition of `cond' and at the
use-site, so the literal should match in any case.
scheme@(guile-user)> (define else #f)
scheme@(guile-user)> (cond (else #t))
$2 = #t
Here the `else' is bound at the site of use, but the comparison still
succeeded, because `else' was matched by name (symbolically), not by
binding (lexically).
But now, with this change:
scheme@(guile-user)> (cond (else #t))
$1 = #t
scheme@(guile-user)> (define else #f)
scheme@(guile-user)> (cond (else #t))
scheme@(guile-user)>
`else' did not match, because it was a different binding.
This case has not changed, however:
scheme@(guile-user)> (let ((else #f)) (cond (else #t)))
scheme@(guile-user)>
So whereas before, including something in a literals list did not
specify anything about the toplevel binding, now it does; which
increases the coupling between your macro and your literals.
For example `eval-when' was depending on the bindings of `eval', `load',
`compile', and `expand' at the macro definition and expansion sites. I
didn't want this, so I changed eval-when to match symbolically
instead -- something that is possible with syntax-case, though not
easily facilitated. With that change, Guile recompiled fine, and passed
tests.
This change allows us to bind keywords, and thereby export them from
modules, and have them available for renaming.
See http://article.gmane.org/gmane.lisp.scheme.reports/317 for more
arguments.
I am considering pushing this change to 2.0.x. We will not be binding
literals by default in 2.0.x however, as that would be incompatible. I
am considering doing that in 2.2, though; dunno.
Comments? See the "lexical-literals" branch in git for more.
Cheers,
Andy
--
http://wingolog.org/
next reply other threads:[~2011-04-29 15:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-29 15:16 Andy Wingo [this message]
2011-05-06 12:17 ` pending branch: lexical-literals Ludovic Courtès
2011-05-06 17:39 ` Andy Wingo
2011-06-30 11:46 ` Andy Wingo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3liytxf3j.fsf@unquote.localdomain \
--to=wingo@pobox.com \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).