Re: Making apostrophe, backtick, etc. hygienic?

[Panicz Maciej Godek]

2015-08-30 16:47 GMT+02:00 Taylan Ulrich Bayırlı/Kammer <address@hidden>:

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.

This could actually be solved by some additional means -- for example, one could have to write some additional statements that would confirm that he's aware that the reader macros are being shadowed. For instance

(define-syntax match

  (syntax-rules (.... quote ....)

    ....))

(assert (syntax-shadows? match 'quote)) ;; removes the warning

But to be honest, I don't think that this is a real problem. The problem manifested itself with the "syntax" form, and not the "quote" form, and I think the reason for that is not just accidental. The "quote" form is more common and more commonly used, while the "syntax" form is exotic and surprising -- especially because everyone unfamiliar would read #' as "hash-quote" rather than "syntax"

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

I think that this is the case for R6RS or R7RS, but as far as I can tell, in R5RS it would be problematic.

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.

You'll never know. While it may seem unlikely to fix quote to mean minus, in mathematical analysis the symbol is often used to mean the derivative of a unary function, so it is quite possible that someone would wish to write in some context

(let ((quote deriv))

  (+ (f x) ('f x) (''f x)))

On the other hand, your soultion would work if someone decided to write

(let ('deriv)

 (+ (f x) ('f x) (''f x)))

(which is IMO more elegant)

Nevertheless, I think that even if 'x would map to (__quote__ x), it could still happen that someone was using the __double_underscore__ convention in her code (for some reason), and your allegations would apply to this new situation as well.

As I said earlier, I think that the problem isn't caused by the fact that 'x is (quote x), because it is likely that every lisp programmer reads 'x as "quote x", but by the fact that there is this weird "syntax" form (and its family) which has only one application in Scheme, namely -- syntax-case macros.

You could ask the question on comp.lang.scheme newsgroup, but I think that the solution you suggest would only introduce unnecessary divergence from Lisp and Scheme, and for a dubious reason. Furthermore, while it is common to use these __underscores__ in C, PHP or Python, it is an alien practice in the Scheme code base. (Instead of "quote x", you'd need to read 'x as "underscore underscore quote underscore underscore x", which is unhandy and brain-damaging)

Regards,

M.