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