John David Stone <xxxxxx@cs.grinnell.edu>:
>         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.

I disagree.  There are only the markers \\, $, and <*...*>,
as well as {...} used for curly-infix lists.
There are *no* exceptions, and no enforced conventions.
Certainly there are useful ways that they can be
conventionally used, but that's a GOOD thing.

This is a *tiny* amount of syntax compared to other languages.
There are no precedence rules, for example, and there are no
special rules for each semantic construct.

Also, trying to have an absolutely minimum syntax ruleset optimizes the wrong thing.
I urge you to look at notations as an engineering problem, and then
focus on questions such as time trade-offs.
If you only spend an hour a year reading Lisp, then you want to minimize syntax since
that will minimize learning time.  But if you spend a lot of time reading Lisp, then
it's better to create a *good* syntax, even if it takes slightly more time to learn.
The time to learn it is amortized over all the code you read.
You can have too much, or too little.  You're welcome to believe that it's too much,
but we're trying to trade off options to produce a notation in a sweet spot.

In particular, it's not true that there is "no syntax" in Lisps.
Even R5RS Scheme has 4 punctuation abbreviations (' and ` and , and ,@).
Also, list notation (a b c ...) abbreviates (a . (b . (c ...))).
Scheme numbers are actually quite complex syntactically; Scheme numbers
require more space, in turns of rules, than the t-expression notation.

In any case, sweet-expressions are clearly homoiconic.  A given expression
can be trivially translated, in a person's head, into the underlying structure.
I can do it quickly, and others have learned how to do it as well.
If you haven't gotten it yet, keep at it; it shouldn't take long to get there.

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

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.

The difference is that in many languages, it's easy for indentation and
nesting to go out of sync.  When indentation has syntactic meaning, there's
no risk that they'll go out of sync.

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

Sure, but that's because in general they weren't homoiconic or general.
It was only obvious in retrospect that these were requirements.

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

Well, it's your right to think we've failed.  I think we've succeeded greatly
in terms of accomplishing the stated goals - make Lisp readable with a notation
that is general, homoiconic, and backward-compatible.

Will people pick it up?  That remains to be seen, but that's a social issue not just
a technical issue.  But it's quite clear that most software developers will NOT
use any Lisp, even where one would be useful, as long as it is limited to
its 1950s-era syntax.

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

Again, this is false.  Indentation *is* a grouping system.
Since programmers *naturally* lay out structure, we're simply using that natural
tendency and making it syntactically meaningful.

The May 2013 edition of the TIOBE programming index has Python at #8,
far higher than Common Lisp or Scheme.  Python has been using
whitespace as a grouping symbol from its beginning.  Thus, it's manifestly false
that a language cannot be popular *and* use indentation for grouping.

--- David A. Wheeler