Comment on SRFI-110 and Comparison to Genyris xyzzy
Bill Birch
(22 May 2013 15:03 UTC)
|
Re: Comment on SRFI-110 and Comparison to Genyris xyzzy
David A. Wheeler
(23 May 2013 13:39 UTC)
|
sweet-expressions are not homoiconic
John David Stone
(23 May 2013 16:08 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(23 May 2013 16:19 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(23 May 2013 16:32 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(24 May 2013 03:55 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(24 May 2013 03:12 UTC)
|
Re: sweet-expressions are not homoiconic John David Stone (24 May 2013 15:34 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(24 May 2013 20:02 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(24 May 2013 20:09 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(24 May 2013 21:35 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(24 May 2013 22:40 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(24 May 2013 23:13 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(25 May 2013 03:43 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(25 May 2013 03:20 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(25 May 2013 04:17 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(25 May 2013 04:27 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(25 May 2013 04:55 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(25 May 2013 18:14 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(26 May 2013 23:26 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 00:29 UTC)
|
Re: sweet-expressions are not homoiconic
John David Stone
(27 May 2013 15:51 UTC)
|
Re: sweet-expressions are not homoiconic
Alan Manuel Gloria
(28 May 2013 04:28 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(28 May 2013 18:34 UTC)
|
Re: sweet-expressions are not homoiconic
Beni Cherniavsky-Paskin
(26 May 2013 20:40 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(26 May 2013 22:43 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 00:00 UTC)
|
Re: sweet-expressions are not homoiconic
Alexey Radul
(27 May 2013 03:32 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 04:44 UTC)
|
Re: sweet-expressions are not homoiconic
Alexey Radul
(27 May 2013 05:50 UTC)
|
Re: sweet-expressions are not homoiconic
Alan Manuel Gloria
(27 May 2013 06:34 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 15:14 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 13:55 UTC)
|
Re: sweet-expressions are not homoiconic
Alexey Radul
(27 May 2013 16:27 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(27 May 2013 15:55 UTC)
|
RE: sweet-expressions are not homoiconic
Jos Koot
(27 May 2013 04:57 UTC)
|
Re: sweet-expressions are not homoiconic
David A. Wheeler
(27 May 2013 13:37 UTC)
|
Re: sweet-expressions are not homoiconic
John Cowan
(27 May 2013 15:50 UTC)
|
-----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-----