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)

sweet-expressions are not homoiconic John David Stone 23 May 2013 15:35 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

        At this point, so many markers, special conventions, and multilayer
exceptions have been added to the proposed syntax that it is quite
implausible to claim that sweet-expressions are homoiconic.  In the general
case, reconstructing the underlying data structure from the
sweet-expression that represents it requires the mental application of a
non-obvious algorithm of considerable intricacy.

        From the beginning, there was an obvious impediment to the use of
sweet-expressions:  Readers who are accustomed to alphabetic writing
systems in which whitespace is almost invariably used as a word separator,
a paragraph separator, a decorative typographical element, or for page
layout simply don't respond psychologically to whitespace characters as
they do to visible characters such as parentheses.  Whitespace characters
don't look like grouping symbols, as parentheses, brackets, braces, or
oriented quotation marks do, because they don't have appropriate shapes and
don't come in pairs.  Moreover, they don't visibly nest, so it is unnatural
to use them to represent recursively defined syntactic structures.

        As the draft SRFI document notes, SRFI 110 is the most recent in a
seemingly endless succession of attempts to construct a syntax for
LISP-like languages that uses fewer parentheses.  All previous attempts
have failed.  The authors of this SRFI argue that those attempts have
failed because they were not general enough to mix well with the classical
LISP syntax or because they obscured the hierarchical syntactic structure
of the code.  They thought that they could avoid these problems.

        However, it is almost impossible to avoid obscuring a hierarchical
syntactic structure if you try to use whitespace as a grouping symbol.
Designers of such alternative syntaxes find themselves adding one epicyclic
extension after another in a futile attempt to reconcile the use of
whitespace for grouping with its natural functions of delimitation and
layout management.  This is what has happened to SRFI 110.  The discussion
archive is a wonderful cautionary tale for future designers who may be
tempted by the same siren song.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.9 <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAlGeNxsACgkQbBGsCPR0ElQhHwCgn+IpH8uRg7HWBuFN+DEmd28t
M+EAoNg2vN6Dn9adTLE/r4zXNJ+s6Nqd
=41F5
-----END PGP SIGNATURE-----