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