[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sweet-expressions are not homoiconic

This page is part of the web mail archives of SRFI 110 from before July 7th, 2015. The new archives for SRFI 110 contain all messages, not just those from before July 7th, 2015.



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

        In an earlier post, I wrote:

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

        To which David Wheeler replied:

 > This is demonstrably false.  Whitespace characters, in the form of indentation,
 > are CURRENTLY used to group structures in pretty much all non-trivial
 > Lisp programs.  People routinely use pretty-printers *specifically* to
 > group and nest structures.  In fact, indentation is used
 > to indicate nesting in practically every programming language.

        No, it's not.  It's used to manage layout, which is one of its
principal purposes in traditional manuscripts and typography.  Very few
programming languages try to use it for grouping -- the ones that I recall
offhand are Python and ABC, but I imagine that there are others.  Those
languages get into slightly less trouble with the idea because programs in
those languages don't use nesting quite as extensively -- the program
structures tend to have shallower hierarchies and more flat constructions
analogous to sequences in Scheme.  But it is also true that Python programs
are more difficult to read and to edit than they would have been if the
designer had chosen to use explicit grouping symbols.

        This confusion between layout and grouping is really the crux of
the issue.  The reason that the parenthesis notation is better is that it
separates these two functions, which both affect readability, but in
different ways.  Using whitespace for _layout_ is, of course, a good idea,
and almost all programmers and programming languages support it.  Using
whitespace for _grouping_ is not such a good idea and doesn't work well
when the groups are deeply nested, as they are in most Scheme code.

        Layout and grouping clearly diverge in the conventions that most
Scheme programmers follow.  For instance, in let-expressions, the binding
specification list and the body are indented differently, even though they
are at the same level as far as syntactic grouping is concerned; this
difference reflects the semantic difference between the syntactic
constituents.

        Another example:  In procedure calls that extend over several
lines, the first operand may be indented differently from the others if it
is semantically related to the operator in a way that differs significantly
from the other operands (e.g., if the procedure is vector-set!, the vector
operand is often indented differently from the index and new-value
operands).

        John Cowan has pointed out that _uniformly_ using whitespace for
grouping would produce programs that make excessive use of vertical space.
This is obviously the case, and it demonstrates that the need to use
whitespace for layout effectively contrains and complicates the use of
whitespace for grouping, leading almost inevitably to the use of marker
characters as syntactic guideposts.

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

iEYEARECAAYFAlGfiD0ACgkQbBGsCPR0ElSBvwCgr1+OZvVS13Wto5awoiyMTsE4
fyAAoI+Hi89WY9sdJ0GwAh3SPXO8ODdT
=nLam
-----END PGP SIGNATURE-----