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)

Re: sweet-expressions are not homoiconic John David Stone 24 May 2013 21:35 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-----