From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Panicz Maciej Godek Newsgroups: gmane.lisp.guile.devel Subject: Re: Making apostrophe, backtick, etc. hygienic? Date: Mon, 31 Aug 2015 13:58:57 +0200 Message-ID: References: <87a8t9gdqy.fsf@T420.taylan> <871tekhq7f.fsf@T420.taylan> <87wpwcg7e2.fsf@T420.taylan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bacb5ba859e06051e9a2895 X-Trace: ger.gmane.org 1441022347 13608 80.91.229.3 (31 Aug 2015 11:59:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Aug 2015 11:59:07 +0000 (UTC) Cc: guile-devel To: =?UTF-8?B?VGF5bGFuIFVscmljaCBCYXnEsXJsxLEvS2FtbWVy?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Aug 31 13:59:07 2015 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZWNju-0004Bd-B0 for guile-devel@m.gmane.org; Mon, 31 Aug 2015 13:59:06 +0200 Original-Received: from localhost ([::1]:36420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWNjt-0006hl-To for guile-devel@m.gmane.org; Mon, 31 Aug 2015 07:59:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWNjp-0006hS-Dc for guile-devel@gnu.org; Mon, 31 Aug 2015 07:59:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWNjn-0007UG-J6 for guile-devel@gnu.org; Mon, 31 Aug 2015 07:59:01 -0400 Original-Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:36877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWNjn-0007U3-7L for guile-devel@gnu.org; Mon, 31 Aug 2015 07:58:59 -0400 Original-Received: by wicfv10 with SMTP id fv10so67735705wic.0 for ; Mon, 31 Aug 2015 04:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zM+GVq7V/5329KJquHdXtmg6jn5i5GIUKc4FhwDTCz8=; b=0ypm2nO55QctY5XPhSG1K2ZBchMEZAZ6imTJXBr330YJXmCnJvJYsnKeFav66/cKdc tOpUyJluOw43JC/LUp/sStaqarbpqhahZ8hyYSuCGlV8wKaJA1vmOY/iA1dW3b8lgjQN fjUctvq6izEPO26SHoJh9OGrBsCyYwvK1gDsp85RHjEQq0ZHEewngMOtukNrMUTOvmnM I6LghexNXBQPqC2qh1fF7pLGS+KPxWw3yRaNi7iKfx6dg9OXrFtjMUMRIzAC9p8AqEN5 MeuMMZsg1gOzD+3BNB0EvgREif269WCO/IgodR265OpcdMiTJWY1V0PzR4s4NWpPTaAh A0Jg== X-Received: by 10.194.59.20 with SMTP id v20mr25520762wjq.61.1441022337193; Mon, 31 Aug 2015 04:58:57 -0700 (PDT) Original-Received: by 10.194.94.69 with HTTP; Mon, 31 Aug 2015 04:58:57 -0700 (PDT) In-Reply-To: <87wpwcg7e2.fsf@T420.taylan> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22e X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17808 Archived-At: --047d7bacb5ba859e06051e9a2895 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-08-30 16:47 GMT+02:00 Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer < taylanbayirli@gmail.com>: > Panicz Maciej Godek 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=3Dguile.git;a=3Dblob;f=3Dmodule/ice= -9/match.upstream.scm;h=3Dede1d43c9ff8b085cb5709678c4227f5ecaaa8a5;hb=3DHEA= D#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) ;=3D> -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. --047d7bacb5ba859e06051e9a2895 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-08-30 16:47 GMT+02:00 Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer <taylanbayirli@gmail.com>:
godek.maciek@gmail.com> writes:

> Your point is that quote (and unquote, and quasiquote, an= d 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 fr= om
> the source code.

Yup, exactly.

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

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

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

(define-syntax match
=C2=A0 (syntax-rules (.... quote ....)
=C2=A0 =C2=A0 ....= ))

(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 &= quot;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 expan= d 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.savan= nah.gnu.org/gitweb/?p=3Dguile.git;a=3Dblob;f=3Dmodule/ice-9/match.upstream.= scm;h=3Dede1d43c9ff8b085cb5709678c4227f5ecaaa8a5;hb=3DHEAD#l335
>
> (match '(a b)
> (('a 'b) #t)
> (_ #f))
>
> would no longer evaluate to #t, because the ('a 'b) pattern wo= uld
> 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<= br> > its purpose) in order to make it work, thus making Guile
> non-RnRS-compliant.

Hmm, that gets a little complicated, yeah.=C2=A0 Still, in highly Rn= RS
compliant systems, macros actually match their "literal" inputs b= y
(hygienic) "bindings" and not the names of identifiers.=C2=A0 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.=C2=A0 (Magic!)=C2=A0 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 R7= RS, 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.=C2= =A0 Like:

=C2=A0 =C2=A0 (let ((quote -)) '9)=C2=A0 ;=3D> -9

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


Yo= u'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 o= f a unary function, so it is quite possible that someone would wish to writ= e in some context

(let ((quote deriv))
= =C2=A0 (+ (f x) ('f x) (''f x)))

O= n the other hand, your soultion would work if someone decided to write

(let ('deriv)
=C2=A0(+ (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 __doubl= e_underscore__ convention in her code (for some reason), and your allegatio= ns 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", b= ut by the fact that there is this weird "syntax" form (and its fa= mily) which has only one application in Scheme, namely -- syntax-case macro= s.

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 u= se these __underscores__ in C, PHP or Python, it is an alien practice in th= e 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)

<= /div>
Regards,
M.=

--047d7bacb5ba859e06051e9a2895--