Panicz Maciej Godek <godek.mac...@gmail.com> 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: > http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=module/ice-9/match.upstream.scm;h=ede1d43c9ff8b085cb5709678c4227f5ecaaa8a5;hb=HEAD#l335 > > (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. Taylan
