indentation-based S-expression syntax (was Re: XML as a transition to s-expr)

[address@hidden (Kragen Sitaker)]

(People who think discussion of indentation-based syntax is "a
discussion of either religion or politics" should stop reading NOW.)

Tony Kimball writes:
> I don't want to write
> 
> cond
>   n < 1
>     1
>   t
>     *
>       n
>       fact
>         -
>           n
>           1
> 
> which looks like someone was playing with the platen while I was
> typing.

How about
  if (< n 1) 1
      * n
        fact (- n 1)
then?  Or even
  if
      < n 1
      1
      * n
        fact
          - n 1
?

(Cond doesn't work well with any of the indentation-based S-expr
syntaxes I've experimented with, either in the traditional (cond
(predicate consequent) (predicate consequent)) form or in the Arc
(cond pred cons pred cons cons) form.)

I *do* like being able to understand expressions in isolation, which
is the major difficulty I have with Lisp.  If I see an expression 
(foo (bar baz)), it could mean any of several things:
- an application of the function foo to the result of (bar baz) --- probably
  the most common meaning
- a conditional clause that says that when foo is true, do (bar baz)
- a let clause that defines foo as the result of (bar baz)
- a list containing both foo and another list consisting of bar and baz
  (of course, it always means this, but sometimes that list remains literal)

Determining which one it means requires looking up at least a level
(which could be arbitrarily far away in the program, and often is at
least several lines away) to determine the context.  In the case of
quoting, I may have to look up an arbitrary number of levels.  It
would help this matter if Emacs font-locking distinguished quoted
expressions from unquoted ones.

Another case of context dependency: if I have two S-expressions next
to each other, their relationship to one another depends on the
context too.  This is a somewhat weaker argument.  I think infix
grammars tend to make the relationship easier to discern.

I think this is a disadvantage of S-expression syntax for programming
languages.  I'm not going to claim that this makes Python's syntax
superior to Common Lisp's or Scheme's, because S-expression syntax has
advantages as well (macroability, Emacs-friendliness), and whether its
disadvantages outweigh its advantages probably depends on the context
in which it is being used.  Furthermore, this disadvantage is
difficult to separate from macroability.

Paul Prescod writes:
>  * the parens do not sufficiently denote "parts of speech". Consider the
> two examples described by this URL:
> 
> http://www.cs.utexas.edu/users/wilson/schintro/schintro_21.html#SEC21

I think that's what I'm describing above.

> I'm going to risk flamage and say that Scheme (not MZScheme or BobScheme
> but R5RS Scheme) does have usability problems. I came to that conclusion
> watching the DSSSL experiment.

What happened in the DSSSL experiment?

> As it is, Scheme errors can be reported miles away from where you
> actually forgot a paren.

And if you forget two parens, possibly not at all.  Note that
indentation-based syntax, especially mixed with optional parens,
solves this problem.

Tony Kimball continues:
> Even Scheme and Forth and APL, which are about as syntax-light as you
> can get, do *have* syntax,

I disagree with the assertion that Forth has syntax.

Christopher Barber writes:
> It is not that indentation is incompatible with markup. It is merely that
> when you tie markup semantics soley to the indentation level, it becomes too
> easy to make mistakes that cannot easily be caught by your editor.

I'm not sure I know what you mean.  Is this the same complaint some
people have about Python, namely that both
    if x:
        y()
    z()
and
    if x:
        y()
        z()
are both valid?  Is that noticeably different, from a HCI perspective,
from <b>y</b>z and <b>yz</b> both being valid?  (I know I've made the
analogous mistake in Lisp from time to time, even with
paren-blinking.)

Christopher Barber also writes:
> Indentation alone works ok with Python code, but it becomes much
> more problematic when text is involved.  Imagine that the content of
> each cell is a paragraph...

Why is this a problem?  Are you thinking that
    """abc
    def"""

should mean "abc\n def", as it does in Python?  The simple solution to
that is for it to mean "abc\ndef", and
    """abc
def"""
to simply be illegal.  Indentation-based syntax should have no
exceptions, especially for literal strings.

-Kragen