[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

pending branch: lexical-literals

From: Andy Wingo
Subject: pending branch: lexical-literals
Date: Fri, 29 Apr 2011 17:16:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

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

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))

`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)))

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

This change allows us to bind keywords, and thereby export them from
modules, and have them available for renaming.

See for more

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]