RE: indentation (was Re: About the article)

["Frank A. Christoph" <christo@xxxxxxxxxxxxxxxxxx>]

Gawd, I should have known better than to open my mouth on this subject...!
The truth is I am an unconscionable syntax terrorist. :P OK, I swear on my
honor this is the last time I will ever make an issue out of
syntax/indentation/what-have-you again. Cross my heart and hope to die.

[Clarification: In the text below, I arbitrarily wrote "de facto style"
where you would write "LISP standard style."]

> >1) In making the transition from an imperative, object-oriented,
Algol-style
> >language like C++ or Java to a declarative, functional,  LISP-style
language
> >like Scheme, syntax is the least important issue. In fact, it is
practically
> >a truism that if the word "syntax" appears in any list ranked by
importance,
> >it always appears at the bottom.
>
> Possibly true.  But what's the point?  Indentation/formatting of  the
source
> is not relevant to the syntax (at least in languages which don't rely on
> BOL/EOL as syntactic markers).

First, let me say that it's true that I unconsciously blurred the
distinction between syntax and presentation. But presenting Scheme syntax as
if it were C syntax is, IMO, counterproductive, and more likely to mislead
people than anything else. In every introductory Scheme class you have to
say something to the effect of, "Syntax: This is prefix notation. This is an
s-expression. This is how an s-expression differs from a block." If you then
turn around and start formatting the Scheme code as if it were C, you are
going to confuse people who start drawing false analogies between the two
based on your presentation.

Let me be more explicit. In C, the order of statement execution is the
direction of the data flow. C programmers associate the statement order in a
block with the "direction of data flow". In DSSSL, the order of
subexpressions in an expression is also the order of execution (or rather,
evaluation), but it is largely irrelevant to the direction of the data flow.
(The direction of data flow is "perpendicular" to this; it follows the
nesting.) Encouraging the similarities between the two will lead C
programmers to rely on the evaluation order rather than the data flow, which
would simply be bad style in Scheme, but is just plain unworkable in DSSSL
(in the absence of recursion, at least). Is the extra sense of security
really worth the very minor additional cognitive load that a new indentation
style places on them?

>  Now if you're trying to argue that the
> formatting of the source is at the bottom of the list in importance (a
> strawman, I think), then I would disagree -- take a look at some of the
> Pascal output by the original WEB processor if you want an easy example

Well, formatting is an issue closely related to concrete syntax, which puts
it near the bottom of the list (although I admit syntax is more important in
LISP/Scheme than, say, C, because of the code-is-data concept). The
importance of source formatting is inversely proportional to the
expressiveness of the source language. Scheme is fairly expressive, as
programming languages go.

I have used CWEB and other literate programming systems, and such things are
certainly nice to have around; I like my code to look fancy, and there are
advantages to having it and the relevant documentation side by side, but on
the other hand I've found that literate systems and formatters and such are
not that significant an aid in high-level languages. On the other hand,
Pascal and C are not very high-level or expressive, and being able to use
additional tools in conjunction with them is almost a necessity.

...Then again, have you every taken a look at the TeX source? It's
beautifully formatted, and very well-documented, but it's still hard to
(correctly) modify and maintain the program itself (uh, I guess---at least,
I sure have trouble following the code, even with those cool mini-cross
references on every other page, etc.).

> >2) I feel that when learning a new language it's best to adopt the
stylistic
> >conventions of its most experienced practitioners. (I believe that this
> >applies to natural languages as well.) It's pretty safe to  assume that
they
> >have good reasons for preferring that style, and obviously it has stood
them
> >in good stead, or otherwise they would not be using that language and/or
> >style. Observe that people who have been writing LISP or Scheme  for a
long
> >time all use the abbreviated blocking style (the one not used in C).
>
> If one were writing a textbook on the subject, I'd be inclined to
> agree.  If one is writing an introductory article, it's less clear to me.
I
> would, in general, prefer to introduce one new idea at a time ... and
since the
> indentation is syntactically meaningless, to choose an indentation style
> best suited to communicating with the reader.
>
>  This may not be the style
> best suited for production programming (although I would argue that code
> readability is equally or more important in production programming, the
> target audience is different).

Better to encourage good habits early, since they tend to stick.

BTW, here are four concrete reasons why I prefer the de facto style. (Yes,
my true colors are showing!)

1) Using whitespace to emphasize the tree structure makes the closing
parentheses mostly redundant for a human reader anyway.

2) Putting closing parentheses on separate lines uses up too many lines in a
language which uses so many parentheses in the first place. It's more
worthwhile to be able to see more of your program at once than it is to have
the added hints regarding the expression nesting.

3) Emacs does it in the de facto way. (Hm, is this a tautology? :)

4) Since everybody else does it that way, conforming means that I have one
less arbitrary decision to contend with in my life.

> >3) Anyone who dismisses a programming language purely because  its syntax
is
> >"weird" is probably incapable of making significant contributions to its
> >code base anyway.
>
> Maybe.  But what does this have to do with the discussion?

Nevermind; I thought you were trying to present the Algolization of DSSSL
syntax as a selling point (like the authors of a certain widely used C++
knockoff did for their language, much to its everlasting detriment).

> >4) Marketing a programming language on the merits of its syntax is a weak
> >and transparent ploy, likely to incur suspicion and distrust among
> >knowledgeable programmers, the people you want to attract the most.
> >Convincing expositions are based on factual evidence and, in their
absence,
> >clear-cut, representative motivating examples, not presentation style.
>
> Then I have failed to communicate the main point I intended.  I'm
> not (and I
> don't think Didier was) arguing that shifting the style of indentation in
> general use would make any particular difference to the advancement or
> decline of DSSSL.  I think the basic thesis was that more general
> publication of "convincing expositions ... based on factual
> evidence and, in their absence, clear-cut, representative motivating
examples"
> would advance the language.

Fair enough.

> Secondarily (and the only point I was addressing) in
> presenting such examples,  a more familiar coding style assists the reader
> in understanding the exposition.

I already addressed this at length, but I also want to point out that
differences in formatting style (as opposed to "coding style", which is a
different issue, and probably not what you meant to write) are only really
significant aids to understanding when the reader is looking at a large
quantity of code. In a teaching environment, one typically uses small
examples and students have ample time and energy to study it. And if you are
presenting a large body of code in such an environment, it should probably
be presented in the de facto style for that language anyway.

>  Presentation style (a bigger topic than
> indentation) cannot make a discussion which is substantively unclear
> suddenly lucid.  But it can reinforce and make easier the
> exposition of new -- and hence difficult -- ideas.

Certainly. I'm saying that your presentation of DSSSL is bad because it
reinforces the wrong ideas (and suppresses the right ones).

> 	A more subtle point is that what indentation (or, if you prefer,
> presentation) style would best aid the target audience to understand the
> discussion.  Implicit in my argument is that the target audience consists
of
> people already accustomed to the "block indent" style of program
formatting.
> Depending on the actual target audience for a particular article, this may
> not be appropriate.  For example, if one were writing an introduction to
> DSSSL for a LISP programming journal, I'd argue just as strongly for
> adopting the "LISP standard" form of blocking and indentation.
>
> 	Perhaps the bottom line is that the style of formatting of the
> source code should be chosen to suit the purpose of the exposition (and I
> include production code in this, since it will be, in general, read many
> more times than written).

If your students (audience, whatever) are C programmers, they will be misled
by the formatting.
If they are experienced programmers in _any_ language, they are certainly
capable of grasping a new syntax without hand-holding or presentational
tricks. If  your students _aren't_ experienced programmers, they will have
the same hurdles to cross, whichever way you present the language, and if
that's the case it's evidently better to present the de facto style from the
start.

--FC


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist