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: Sun, 30 Aug 2015 15:57:54 +0200 Message-ID: References: <87a8t9gdqy.fsf@T420.taylan> <871tekhq7f.fsf@T420.taylan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bfcf9c81f48f4051e87b438 X-Trace: ger.gmane.org 1440943083 26853 80.91.229.3 (30 Aug 2015 13:58:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Aug 2015 13:58:03 +0000 (UTC) Cc: guile-devel To: =?UTF-8?B?VGF5bGFuIFVscmljaCBCYXnEsXJsxLEvS2FtbWVy?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Aug 30 15:58:01 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 1ZW37Q-0000lj-Ox for guile-devel@m.gmane.org; Sun, 30 Aug 2015 15:58:01 +0200 Original-Received: from localhost ([::1]:58731 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZW37R-0003Hg-RF for guile-devel@m.gmane.org; Sun, 30 Aug 2015 09:58:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZW37N-0003HR-T1 for guile-devel@gnu.org; Sun, 30 Aug 2015 09:57:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZW37L-00017A-W2 for guile-devel@gnu.org; Sun, 30 Aug 2015 09:57:57 -0400 Original-Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:33097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZW37L-00016n-JM for guile-devel@gnu.org; Sun, 30 Aug 2015 09:57:55 -0400 Original-Received: by wicpl12 with SMTP id pl12so8492765wic.0 for ; Sun, 30 Aug 2015 06:57:55 -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=ktbbylqp4V9E+49moJCVUGNpDznk4BLWCY8j7oaRXZk=; b=V19Td5baXjS2PEdCN1DA/C4P99E96PxsnJhsqfsyVCjwRqCHh8rJG7av/XSEHNFdI0 CRThsUwFJTsh58XqQwp+g3j9yhc29mb27tm981oJSlgPZdAqWsYNl/ecKfzUSJ3v+jCe gkDblZ77ULz0lrFn45CW3xNCIdFl4+jXw2gjtB0ElpOMt0C0Sa9IujjSssgToZk2z7St 683XY6GAIDIr1suipA7xrDeNbtY0+ssFGj98u/fzj1kzz2z03Xw6sxMQtXsn7I8c79Eq AU4LkTUJSAVqtEPVFN8RloIZEsf9mATdINly5XPTv8qWbIoWBjKYaEu4YiLdvKlMZ5ks 3hxw== X-Received: by 10.194.90.70 with SMTP id bu6mr21933848wjb.149.1440943074918; Sun, 30 Aug 2015 06:57:54 -0700 (PDT) Original-Received: by 10.194.94.69 with HTTP; Sun, 30 Aug 2015 06:57:54 -0700 (PDT) In-Reply-To: <871tekhq7f.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::22f 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:17806 Archived-At: --047d7bfcf9c81f48f4051e87b438 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-08-30 15:16 GMT+02:00 Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer < taylanbayirli@gmail.com>: > Panicz Maciej Godek writes: > > > You mean that #'x is synonymous to (syntax x), and that's where the > > problem stems from? > > Yup. I shadow 'syntax', but I don't explicitly shadow "#'". It gets > shadowed implicitly. Lexical scoping and hygiene are supposed to let > the programmer forget about such worries. > > > I think that every lisper should know that 'x is synonymous to (quote > > x), and in some contexts it might be desirable to bind a new meaning > > to the "quote" form (and this is already done by some libraries, > > notably in the (ice-9 match) module). > > One may know, but still forget when sufficiently tired, and/or when > using the word "quote" to mean something conceptually different than the > quoting in lisp. > You could say that about practically any keyword in Scheme, or for that matter any other language. The advantage of Scheme is that it really allows you to redefine any keyword you like. 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. > For instance, some kind of text processing program might give the term > "quote" a specific meaning in the program's problem domain, and once > you're immersed deeply enough in this domain, you might find yourself > naming some function parameter "quote" without giving it a second > thought. Kind of difficult to explain what I mean, but I know it > happens to me when I'm not careful. 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. > As another example, it also keeps > happening to me that I write code like: > > (syntax-rules () > ((_ foo) > (begin > ... > (let ((foo bar)) > ...)))) > > where I forget that the 'foo' there will not be bound freshly by that > let form, and that despite that I understand how 'syntax-rules' works > very well (externally, not necessarily internally!). One is just > accustomed to be able to let-bind whatever one wants, and lexical > scoping and hygiene take care of all worries ... except when not. :-) > (In this case it has nothing to do with quote/syntax/etc., just giving > an example of what silly mistakes I can make when not careful.) > > Well, misspellings happen all the time, but I think that just as their consequences can usually be avoided in real life by use of sanity, unit-testing your code is the best way to make sure that it is sane. > (Nowadays I name all my pattern variables for that reason. Reads > like BNF too, which is nice. And I don't see it ever clashing with > record type names in practice.) > > > As to "syntax", the use of #'x is much rarer, and the idea that #'x is > > (syntax x) is indeed a bit controversial. But this regards the whole > > syntax-case macro system, and I think that it would be more valuable > > to think how to fix its flaws, rather than change the very > > fundamentals of the language. > > Hmm, I'm not sure what flaws of syntax-case you have in mind. IMO it's > a pretty nice system. syntax-rules are nice, because they allow to comprehend macro transformations in terms of textual substitutions (as it is the case with functional programming), but because they expand in normal (rather than applicative) order, it's difficult to write more complex macros. The well-known solution is to use CPS macros (which are very difficult to comprehend) or Oleg Kiselyov's idea to implement the CK abstract machine in them. The third way, often the most intuitive, to influence the order of expansion, is to use syntax-case. However, if you do so, you can no longer (in general) analyze the macros in terms of textual substitution. And you need to use some new weird special forms, like the aforementioned "syntax" But either way, I don't think making #'foo expand > to (__syntax__ foo), and simply making __syntax__ a synonyms to syntax, > are fundamental changes. 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=3DHEAD#= 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. --047d7bfcf9c81f48f4051e87b438 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015= -08-30 15:16 GMT+02:00 Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer <tayla= nbayirli@gmail.com>:
Pan= icz Maciej Godek <godek.maciek= @gmail.com> writes:

> You mean that #'x is synonymous to (syntax x), and that's wher= e the
> problem stems from?

Yup.=C2=A0 I shadow 'syntax', but I don't explicitly sha= dow "#'".=C2=A0 It gets
shadowed implicitly.=C2=A0 Lexical scoping and hygiene are supposed to let<= br> the programmer forget about such worries.

> I think that every lisper should know that 'x is synonymous to (qu= ote
> x), and in some contexts it might be desirable to bind a new meaning > to the "quote" form (and this is already done by some librar= ies,
> notably in the (ice-9 match) module).

One may know, but still forget when sufficiently tired, and/or when<= br> using the word "quote" to mean something conceptually different t= han the
quoting in lisp.

You could say that abo= ut practically any keyword in Scheme, or for that matter any other language= . The advantage of Scheme is that it really allows you to redefine any keyw= ord you like. Your point is that quote (and unquote, and quasiquote, and sy= ntax, and unsyntax, and quasisyntax) is a reader macro, so one might forget= that 'x is really (quote x) -- because that indeed cannot be infered f= rom the source code.
=C2=A0
For instance, some kind of text processing program might give the term
"quote" a specific meaning in the program's problem domain, a= nd once
you're immersed deeply enough in this domain, you might find yourself naming some function parameter "quote" without giving it a second=
thought.=C2=A0 Kind of difficult to explain what I mean, but I know it
happens to me when I'm not careful.

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.
=C2=A0
=C2=A0 As another e= xample, it also keeps
happening to me that I write code like:

=C2=A0 =C2=A0 (syntax-rules ()
=C2=A0 =C2=A0 =C2=A0 ((_ foo)
=C2=A0 =C2=A0 =C2=A0 =C2=A0(begin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(let ((foo bar))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...))))

where I forget that the 'foo' there will not be bound freshly by th= at
let form, and that despite that I understand how 'syntax-rules' wor= ks
very well (externally, not necessarily internally!).=C2=A0 One is just
accustomed to be able to let-bind whatever one wants, and lexical
scoping and hygiene take care of all worries ... except when not. :-)
(In this case it has nothing to do with quote/syntax/etc., just giving
an example of what silly mistakes I can make when not careful.)


Well, misspellings happen all the time= , but I think that just as their consequences can usually be avoided in rea= l life by use of sanity, unit-testing your code is the best way to make sur= e that it is sane.
=C2=A0
(Nowadays I name all my pattern variables <foo> for that reason.=C2= =A0 Reads
like BNF too, which is nice.=C2=A0 And I don't see it ever clashing wit= h
record type names in practice.)

> As to "syntax", the use of #'x is much rarer, and the id= ea that #'x is
> (syntax x) is indeed a bit controversial. But this regards the whole > syntax-case macro system, and I think that it would be more valuable > to think how to fix its flaws, rather than change the very
> fundamentals of the language.

Hmm, I'm not sure what flaws of syntax-case you have in mind.=C2= =A0 IMO it's
a pretty nice system.

syntax-rules are nic= e, because they allow to comprehend macro transformations in terms of textu= al substitutions (as it is the case with functional programming), but becau= se they expand in normal (rather than applicative) order, it's difficul= t to write more complex macros.
The well-known solution is to use= CPS macros (which are very difficult to comprehend) or Oleg Kiselyov's= idea to implement the CK abstract machine in them.
The third way= , often the most intuitive, to influence the order of expansion, is to use = syntax-case. However, if you do so, you can no longer (in general) analyze = the macros in terms of textual substitution. And you need to use some new w= eird special forms, like the aforementioned "syntax"
But either way, I don't think making #'foo= expand
to (__syntax__ foo), and simply making __syntax__ a synonyms to syntax,
are fundamental changes.=C2=A0

Putting the= issue with "syntax" aside, making 'foo expand to (__quote__ = foo) would be surprising to anyone who actually wanted to shadow "quot= e". As I mentioned earlier, there are libraries that make use of the f= act that 'x is (quote x). Take a look in here, for example:
<= a href=3D"http://git.savannah.gnu.org/gitweb/?p=3Dguile.git;a=3Dblob;f=3Dmo= dule/ice-9/match.upstream.scm;h=3Dede1d43c9ff8b085cb5709678c4227f5ecaaa8a5;= hb=3DHEAD#l335">http://git.savannah.gnu.org/gitweb/?p=3Dguile.git;a=3Dblob;= f=3Dmodule/ice-9/match.upstream.scm;h=3Dede1d43c9ff8b085cb5709678c4227f5eca= aa8a5;hb=3DHEAD#l335

(match '(a b)
=C2=A0 (('a 'b) #t)
=C2=A0 (_ #f))

would no longer evaluate to #t, because the ('a 'b) pattern w= ould actually be read as ((__quote__ a) (__quote__ b)). You'd need to c= hange 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.

--047d7bfcf9c81f48f4051e87b438--