[Top][All Lists]

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

Re: Making apostrophe, backtick, etc. hygienic?

From: Taylan Ulrich Bayırlı/Kammer
Subject: Re: Making apostrophe, backtick, etc. hygienic?
Date: Sun, 30 Aug 2015 16:47:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Panicz Maciej Godek <address@hidden> writes:

> Your point is that quote (and unquote, and quasiquote, and syntax, and
> unsyntax, and quasisyntax) is a reader macro, so one might forget that
> 'x is really (quote x) -- because that indeed cannot be infered from
> the source code.

Yup, exactly.

> You've got the point, but I think that the only reasonable solution
> would be to make the compiler issue warning whenever reader macro
> identifiers are being shadowed.

That's a good idea as well.  It might annoy some users though, when they
really want to shadow 'quote' (or 'syntax').  Dunno.

> Putting the issue with "syntax" aside, making 'foo expand to
> (__quote__ foo) would be surprising to anyone who actually wanted to
> shadow "quote". As I mentioned earlier, there are libraries that make
> use of the fact that 'x is (quote x). Take a look in here, for
> example:
> (match '(a b)
> (('a 'b) #t)
> (_ #f))
> would no longer evaluate to #t, because the ('a 'b) pattern would
> actually be read as ((__quote__ a) (__quote__ b)). You'd need to
> change all occurences of "quote" with "__quote__" in the
> match.upstream.scm (and in every other library that shadows quote for
> its purpose) in order to make it work, thus making Guile
> non-RnRS-compliant.

Hmm, that gets a little complicated, yeah.  Still, in highly RnRS
compliant systems, macros actually match their "literal" inputs by
(hygienic) "bindings" and not the names of identifiers.  I.e., if the
quote and __quote__ identifiers hold the *same binding*, then a macro
that has 'quote' in its literals list will also match '__quote__' for
that literal.  (Magic!)  I seem to remember Guile 2.2 really does this
the pedantically right way, while Guile 2.0 is more lax about it.

This would even help those libraries then.  The user could shadow the
'quote' identifier's binding locally, meaning 'match' is going to reject
it because it's not the binding which 'match' knows, but 'foo will keep
working in 'match' because it will expand to '__quote__' which has not
been shadowed and so still holds the same binding as the 'quote' binding
with which 'match' was defined.

The only RnRS-compliant code that would break is code which itself
shadows 'quote' and expects its shadowing to work with 'foo.  Like:

    (let ((quote -)) '9)  ;=> -9

Dunno if there's any serious Scheme/Guile code out in the wild which
actually relies on this working.


reply via email to

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