Comment on SRFI-110 and Comparison to Genyris xyzzy
Bill Birch
(22 May 2013 15:03 UTC)
|
Re: Comment on SRFI-110 and Comparison to Genyris xyzzy
David A. Wheeler
(23 May 2013 13:39 UTC)
|
sweet-expressions are not homoiconic
John David Stone
(23 May 2013 16:08 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(23 May 2013 16:19 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(23 May 2013 16:32 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(24 May 2013 03:55 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(24 May 2013 03:12 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(24 May 2013 15:34 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(24 May 2013 20:02 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(24 May 2013 20:09 UTC)
|
Re: sweet-expressions are not homoiconic John David Stone (24 May 2013 21:35 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(24 May 2013 22:40 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(24 May 2013 23:13 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(25 May 2013 03:43 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(25 May 2013 03:20 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(25 May 2013 04:17 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(25 May 2013 04:27 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(25 May 2013 04:55 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(25 May 2013 18:14 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(26 May 2013 23:26 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 00:29 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(27 May 2013 15:51 UTC)
|
Re: sweet-expressions are not homoiconic
Alan Manuel Gloria
(28 May 2013 04:28 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(28 May 2013 18:34 UTC)
|
Re: sweet-expressions are not homoiconic
Beni Cherniavsky-Paskin
(26 May 2013 20:40 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(26 May 2013 22:43 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 00:00 UTC)
|
Re: sweet-expressions are not homoiconic
Alexey Radul
(27 May 2013 03:32 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 04:44 UTC)
|
Re: sweet-expressions are not homoiconic
Alexey Radul
(27 May 2013 05:50 UTC)
|
Re: sweet-expressions are not homoiconic
Alan Manuel Gloria
(27 May 2013 06:34 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 15:14 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 13:55 UTC)
|
Re: sweet-expressions are not homoiconic
Alexey Radul
(27 May 2013 16:27 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(27 May 2013 15:55 UTC)
|
RE: sweet-expressions are not homoiconic
Jos Koot
(27 May 2013 04:57 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 13:37 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(27 May 2013 15:50 UTC)
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Wheeler writes: > Programmers ALREADY use layout to reveal programming > structure, even in languages where there's no syntactic need to do so. > Since people ALREADY do this, let's take advantage of it. Once again, I disagree. As the examples I cited previously show, programmers prefer to use whitespace for readability and other broadly rhetorical purposes, even when these goals conflict with the goal of indicating syntactic structure. I'll add one more example that happens to have come up recently in connection with the R7RS vote. One of the reasons that Mikael More voted against R7RS (in http://lists.scheme-reports.org/pipermail/scheme-reports/2013-May/003415.html) was that it requires the definitions in a library to be nested inside a begin-expression, which in turn is nested inside a define-library expression. Mr. More offered the following suggestion: "Please find a way so that the library body in the library definition file is at the top level," because he considered "a requirement that >99% of the Scheme code in existence needing to be made within a particular form and indented accordingly" to be "peculiar." In reply (http://lists.scheme-reports.org/pipermail/scheme-reports/2013-May/003430.html), Alexey Radul offered a counter-suggestion: "How hard would it be to program your text editor to give zero indentation to the body of a define-library form that appears at the top level of a file?" Of course, it's really straightforward to tell an editor to display a library file in this way -- unless indentation is used to indicate grouping rather than for layout. Then it becomes problematical. So Radul is right for the classical Scheme syntax, and More is right for the sweet-expression syntax. > Other languages that consider indentation in some way include > Haskell, Occam, and Icon. Well, Haskell does have the layout rule, and I have to admit that it's more widely used by Haskell programmers that the braces-and-semicolon syntax that I'd prefer (though Haskell still supports the latter). Icon does feature syntactically significant whitespace, in that newline can be used as alternative statement terminator, in place of a semicolon. This was a serious design blunder in Icon, since it requires the programmer to think very carefully about the low-level syntactic structure of any statement that extends over more than one line, to avoid breaking lines in places where a statement could terminate. This is also not good for homoiconicity. But indentation is _never_ used for _grouping_ in Icon, which has the usual repertoire of braces, brackets, and parentheses and uses them pretty much as they are used in C. Indeed, as the Griswolds say on page 33 of _The Icon programming language_ (third edition), "Even if braces are not necessary [because, as in C, they are optional when they enclose a single statement], using them helps avoid errors that may result from unexpected groupings in complicated expressions. Using braces to delimit expressions also can make programs easier to read -- it is difficult for human beings to parse nested expressions." I've never studied Occam, so I didn't know about its constraints on whitespace. I found it interesting that, when I did a Google search for "indentation in Occam," the context that Google provided for the first link to a tutorial document was this: % Mar 13, 2013 – The syntax of occam tends to put some people off, as the % compiler insists on "correct indentation". Below is a small occam % fragment ... This suggests to me that using indentation for grouping is probably not the key to widespread popularity as a programming language. In summary: Wheeler has a point about the Haskell layout rule, and of course I can't deny that Python is currently more widely used than Scheme. But citing the Icon and Occam examples only weakens his case, in my opinion. > It's not a confusion. It's an intentional use of layout for grouping. No. Layout is something that one can use whitespace, including indentation, to achieve; it's an end, not a means. Grouping is an alternative end, one that Wheeler is also trying to achieve using whitespace. The evolution of this SRFI and the parallel experiences of previous would-be reformers of LISP syntax show that using the same means to both ends doesn't work very well and often leads to the introduction of _ad hoc_ syntactic kludges. > If you have a long sequence in a deep nesting, just > use "!" to visually show the alignment. Problem solved. > In sweet-expressions, short binding specs can be surrounded by <*...*>, e.g.: > let <* binding-spec... *> > ! body > > Long binding specs can use group, e.g.: > let > ! \\ > ! ! binding-specs.... > ! body... > You can have differing indentation ... by using "\\". I perceive that Wheeler is content with, and even proud of, these kludges. My original point, however, was that they detract, both severally and cumulatively, from the SRFI's stated goal of homoiconicity. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.9 <http://mailcrypt.sourceforge.net/> iEYEARECAAYFAlGf3JgACgkQbBGsCPR0ElSyugCfZpq2SlMJF2aalNtiOIbvpRqq UrUAnjBcl8+0fFkRsuDQDcxdBneFDil6 =HbdO -----END PGP SIGNATURE-----