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

        The rationale section of SRFI 110 acknowledges that previous
attempts to deparenthesize LISP-like languages have regularly come to
grief, but argues that this one will be different, because it will preserve
the homoiconicity of the parenthesis notation:  In effect, the goal was to
make grouping manifest in a way that reflects the actual syntactic
structure of the code, just as the parenthesis notation does.

        Homoiconicity, although it promotes readability, is not the same
thing as readability.  As previous contributors have pointed out,
readabiilty is subjective and endlessly debatable.  Homoiconicity, as its
Greek etymology indicates (_homos_ = "one and the same", _eikazo_ =
"liken"), requires something more: a _formal resemblance_ between the
symbol and the thing symbolized.  Parentheses are homoiconic grouping
symbols because they visibly enclose the grouped items, as if between
walls, and are curved toward one another to hint at the perpendicular walls
that would complete the encirclement of the group.

        In prose, indentation is also, at least arguably, homoiconic for
grouping, because the wider bands of text above and below a block quotation
also visibly resemble walls, and the wider left and right margins create a
sense of constraint and confinement of the text between them.  The basic
plan of SRFI 110 originally was to try to exploit this, offering an
alternative to the supposedly excessive parenthesization that characterizes
LISP-like languages.

        The suggestion was that SRFI 110 might succeed when other similar
projects had failed because it would respect this homoiconicity, ensuring
that human readers would be enabled by the shape of the code itself, and
the shapes of the component symbols, to determine its syntactic structure
effortlessly.

        As the project evolved, however, it ran into the same sorts of
difficulties as earlier attempts to deparenthesize LISP-like languages:
ambiguous constructions, awkwardness at the points of transition between
the parenthesis notation and the sweet-expression syntax, and (most of all)
conflicts between the use of whitespace for grouping and its traditional
role in layout, which often reflects the semantic and rhetorical
characteristics of programs rather then their syntactic structure.

        These difficulties were accommodated by adding special characters
and symbols to the notation.  Not all of the choices were completely
without iconic value:  An exclamation point looks kind of like a vertical
wall, connecting the header at the top of a construction with the matching
bit at the bottom that terminates it.  (Unfortunately, in most
sweet-expressions, there is no matching bit at the bottom; the wall rests
on nothing.)  The <* and *> pair at least work as brackets, even though
nothing in their form suggests "collection list" as opposed to any other
kind of a group.

        On the other hand, there is nothing about the \\ and $ symbols that
represents the corresponding syntactic structures, and indeed \\ is used in
two completely different ways, depending on context.  It even has two
different names, GROUP and SPLIT, as if to emphasize the impossibility of
making the same symbol serve as an icon for two unlike syntactic
operations.

        Sweet-expressions also undermine the (slight but reliable) iconic
status of some of Scheme's existing marker symbols (quote, quasiquote, and
unquote), making them context-dependent.  (For the record: quote is
somewhat iconic because its form suggests a half-barrier, allowing parsing
to proceed but blocking evaluation.  Quasiquote and unquote are slightly
iconic because unquote is an inverted quasiquote character, and its effect
is to undo the effect of the quasiquote.)  All depend for their iconicity on
their immediate juxtaposition to the form to which they are attached.  This
attachment is lost in sweet-expressions.

        The counterargument that sweet-expressions are highly readable to
people who have spent half an hour mastering the rules is not to the
point.  Other proposals to deparenthesize LISP-like languages have also
resulted in programs that were readable to the people who were trained to
read them.  (And, of course, Python programmers can easily read many Python
programs, FORTRAN programmers can easily read FORTRAN programs, etc.)  The
claim, however, was that this time around deparenthesization would succeed,
because sweet-expressions would be homoiconic.  But they aren't.

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

iEYEARECAAYFAlGjgOkACgkQbBGsCPR0ElTougCfeziHMbX9Ly6EeKC8IOLIRz2L
qDQAoJjrdYcaavBwrB4Knq+3xCPFv/mp
=g9PG
-----END PGP SIGNATURE-----