-----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-----