John David Stone <xxxxxx@cs.grinnell.edu> wrote:
>         I'll add one more example that happens to have come up recently in
> connection with the R7RS vote.  One of the reasons that Mikael More voted
> against R7RS (in
> http://lists.scheme-reports.org/pipermail/scheme-reports/2013-May/003415.html)
> was that it requires the definitions in a library to be nested inside a
> begin-expression, which in turn is nested inside a define-library
> expression.  Mr. More offered the following suggestion: "Please find a way
> so that the library body in the library definition file is at the top
> level," because he considered "a requirement that >99% of the Scheme code
> in existence needing to be made within a particular form and indented
> accordingly" to be "peculiar."
>
>         In reply
> (http://lists.scheme-reports.org/pipermail/scheme-reports/2013-May/003430.html),
> Alexey Radul offered a counter-suggestion: "How hard would it be to program
> your text editor to give zero indentation to the body of a define-library
> form that appears at the top level of a file?"
>
>         Of course, it's really straightforward to tell an editor to display
> a library file in this way -- unless indentation is used to indicate
> grouping rather than for layout.  Then it becomes problematical.  So Radul
> is right for the classical Scheme syntax, and More is right for the
> sweet-expression syntax.

It's certainly true that in some contexts (particularly module systems) you need
to create lists in lists... and then mentally "start over" inside them
at the left-hand edge.

But we already anticipated this.
Collecting lists, <*...*>, completely resolve this issue.

So while you point out a legitimate issue, it's an issue
we have already identified and solved.

>  > Other languages that consider indentation in some way include
>  > Haskell, Occam, and Icon.
>
>         Well, Haskell does have the layout rule, and I have to admit that
> it's more widely used by Haskell programmers that the braces-and-semicolon
> syntax that I'd prefer (though Haskell still supports the latter).

It sounds to me that you prefer braces-and-semicolons because, well,
you prefer braces-and-semicolons.  It's perfectly fine to have a
preference, but that is not a reasoned argument that we can address.

...

>         In summary:  Wheeler has a point about the Haskell layout rule, and
> of course I can't deny that Python is currently more widely used than
> Scheme.  But citing the Icon and Occam examples only weakens his case, in
> my opinion.

Python alone makes my case quite strong.  I noted that there are other
languages too, primarily to show that Python is not unique.

We can argue about Icon and Occam and Haskell, but that's not really the point.
I don't think indentation is *NECESSARY* to make a useful language.
I routinely use languages like C and Java where they aren't syntactically meaningful.

But given the current goals and constraints (improve Lisp readability while
being homoiconic, general, and maximally backwards-compatible), I think
making indentation syntactically meaningful is a useful way to solve it.
I view notations as an engineering exercise, and given the constraints,
syntactically-relevant indentation seems to be one of the best tools to help solve it.

If you don't like syntactically-relevant indentation, but DO want infix and name-prefixing,
SRFI-105 may be what you want.  You can use (...) to your heart's content.
But while that *is* an improvement, we can do better, by building on SRFI-105
and adding indentation processing.

>  > It's not a confusion.  It's an intentional use of layout for grouping.
>
>         No.  Layout is something that one can use whitespace, including
> indentation, to achieve; it's an end, not a means.  Grouping is an
> alternative end, one that Wheeler is also trying to achieve using
> whitespace.  The evolution of this SRFI and the parallel experiences of
> previous would-be reformers of LISP syntax show that using the same means
> to both ends doesn't work very well and often leads to the introduction of
> _ad hoc_ syntactic kludges.
...
>         I perceive that Wheeler is content with, and even proud of, these
> kludges.  My original point, however, was that they detract, both severally
> and cumulatively, from the SRFI's stated goal of homoiconicity.

What you see as kludges, I see as necessary aids to readability and usability.
*Removing* these features is of course theoretically possible, but removing them all
would result in a notation that is simple and useless.

Simplicity is a useful goal, but it must not be the only one.
The simplest notation by some measures has only 2 symbols, 0 and 1 in sequence.
But I don't want to read or write stuff that way.

What I *can* say is that JUST depending on parens to do all structuring
has been widely rejected by the vast majority of software developers.
Trying to use both [...] and (...) to create distinguished pairs, e.g., R6RS, hasn't really helped.
Simplistic layout rules turn out to be just that... too simplistic for REAL use.

So we need something else.  I've been having public discussions about this
since around 2006, and this is the best we've been able to develop.

Do you have a specific recommendation instead?  At this late date I'd be unlikely
to accept radical changes, but what the heck, if you have a good idea I'm listening.
But complaining that "I don't like the additional markers" isn't very compelling,
especially since you've simultaneously pointed out (1) why they exist (e.g., excessive vertical
space use) and (2) cases where they are needed (e.g., module systems).

--- David A. Wheeler