andrew@hammer.UUCP (10/24/86)
If you think it's easy to misplace a curly brace, you ain't seen
nothing until you go looking for the subtle program misbehavior caused
by incorrect indentation!
An alternate proposal, which would lead to a more redundant, robust
language, would be to require that the programmer use BOTH punctuation
and indentation. If one or the other is omitted, the compiler can
sense and publish the error.
"Language design isn't dead yet."
These syntactic sugar discussions (how do you spell block begin/end?)
are the least interesting and most trivial part of language design. If
you're interested in language design-by-committee, check out your
favorite ANSI standards group. There are still a lot of meaty issues
to argue over.
-=- Andrew Klossner (vice chair, ANSI BASIC committee)
(decvax!tektronix!tekecs!andrew) [UUCP]
(tekecs!andrew.tektronix@csnet-relay) [ARPA]brad@looking.UUCP (Brad Templeton) (10/25/86)
In article <2642@hammer.TEK.COM> andrew@hammer.UUCP writes: >If you think it's easy to misplace a curly brace, you ain't seen >nothing until you go looking for the subtle program misbehavior caused >by incorrect indentation! True, and very important. Indentation is guaranteed to balance out by the end of the program. There's no such thing as an error, as far as the compiler can detect (except in a few cases where extra keywords like else appear). If you're using a regular text editor, using indentation can be very dangerous. As Mr. Klossner suggests, the correct suggestion is to use both closers and indentation, redundantly. Since the indentation supplies the visual cues, the closers should be unobtrusive, but present. > >These syntactic sugar discussions (how do you spell block begin/end?) >are the least interesting and most trivial part of language design. Anything that people want to debate is (I say by definition) and important issue in language design. For a language to be good, it must be liked. If there is something, even syntactic sugar, that has a strong affect on public perception of the language, it is an important issue. One of the primary purposes of high level languages is human readability. That's what syntax is all about. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
lat@druil.UUCP (TepperL) (10/27/86)
In article <694@looking.UUCP>, brad@looking.UUCP writes: > In article <2642@hammer.TEK.COM> andrew@hammer.UUCP writes: > >If you think it's easy to misplace a curly brace, you ain't seen > >nothing until you go looking for the subtle program misbehavior caused > >by incorrect indentation! > > True, and very important. Indentation is guaranteed to balance out by the > end of the program. There's no such thing as an error, as far as the compiler > can detect (except in a few cases where extra keywords like else appear). I think that the issue isn't so much removing all punctuation, but merely making a judicious choice in what is required and what is optional. In the vast majority of C code I've ever seen, there is usually just one statement per line. I've looked at a lot of the UNIX source code. That means to me that in a new C-like language, one could: 1) Add new-line as a statement terminator 2) Let semi-colon stand as a statement terminator, but drop the <requirement> for it. Semi-colon would then be used for multi-statement lines. I guess that makes it a statement separator. 3) Add something like <back-slash><new-line> to indicate a statement continued across line boundaries. I've been bitten by the bad-indentation bug myself. Problems like that are tough to find. The typical way that it happens to me goes something like this: Write a while loop with a one-statement body: while (condition) do something; The program is working right, so I add some debug: while (condition) fprintf(stderr, "Hi, I got to the loop, n = %d\n"m ); do something; You get the idea. I've introduced another bug with my debug code. What I've found out recently is that a lot of times when I write single statement loops without curly braces, it turns out that sooner or later I have to add them anyway as the loop grows. Here's what I propose for a new C-like language: 1) Require curly braces in all loops. 2) Drop the requirement for parentheses in the condition statement. This means you wouldn't have to do any more typing than before, and the language would prevent you from getting bitten by the incorrect-indentation bug. -- Larry Tepper {ihnp4 | allegra}!drutx!druil!lat +1-303-538-1759
guido@mcvax.uucp (Guido van Rossum) (10/31/86)
[Context appended at end of article]
The difference between misplaced braces bugs and misplaced indentation
bugs is that misplaced (often: missing) braces are hard to find.
See posted example (loop with one-line body + added debug statement).
On the other hand, misplaced indentation is immediately spotted by the
human reader, e.g. (using a language I am familiar with as example):
PUT "" IN name
GET.CHAR c
WHILE 'a' <= c <= 'z':
WRITE c
PUT name^c IN name
GET.CHAR c \ Bug! should be indented more
Here, I would say, you notice the bug even while you are typing it, or
if not, you'll catch it immediately when you peruse the program again
after you find it gets stuck in an infinite loop. Thus, I find
indentation sufficient.
Sure, it's too late to add this, or any of the other proposed
"improvements", to an existing language like C, or even to a new language
that wants to be compatible, like C++. With computer languages, there
is no "next year's model" which you can load with all the features you
find missing in this year's model. Instead, there are longer-lasting
"generations" where members of two or three generations live together,
the young ones learning from the mistakes of old timers, some old
timers picking up a few new ideas (Fortran seems to be in its third
youth!), and the real future of the country being in the hand of
youngsters that nobody takes serious yet.
Sometimes a there is a real "wave movement": the third generation goes
back to ideas of the first, that were utterly rejected by the second
generation. An example is free formatting. When I was a kid, I learned
that the free format of Algol was an improvement over Fortran's rigid
"one statement per line" structure. (In Algol you could use a minimum
number of punched cards for your program by formatting as in a massive
block, but it also allowed the liberal insertion of spaces and
indentation to display the program's intended meaning, as opposed to
the interpretation understood by the compiler.) Very-high level
languages such as Prolog and ABC again have one statement per line, and
I've seen newly designed languages *with* goto statements! Also, in C,
two statements on a line feel like a cardinal sin to me.
Some more mundane points: the issues of mixing spaces and tabs are
utterly system-dependent; when moving a file from one system to another
with a different tab stop interpretation you should do a conversion,
just like when converting from ASCII to CDC DISPLAY CODE. A practical
problem may be that the conventions of the originating system are not
known, and that users may set their own conventions (":se ts=4") that are
not always understood by all tools in the programming environment.
Luckily, auto-indent text editors are commonplace so typing in the
indentation is no problem. If your indentation gets so deep there is no
room for your statements on the line it is probably time to introduce
another level of subroutines anyway. A form of indentation commonly
found in Pascal programs is ridiculous: small indentation steps (one or
two spaces) with one step for each syntactical production:
case i in
1:
begin
if i=j then
begin
stuff;
end
else
morestuff
end
end
This makes it very hard to find matching begin/end pairs, especially if
they span a page or two. Of course, this is neither an argument against
Pascal nor against indentation: it only shows that religious application
of any principle by small minds doesn't create great software. (Cf. the
goto debate.) In my opinion, indentation should be displayed as at
least three or four space. The 8 commonly used in C are excessive, but
the only solution that is portable *and* easy to type.
Syntax-directed editors can suggest an increase of indentation after
certain statements like IF, FOR, WHILE. Decreasing the indentation
again must be done manually, and I've struggled with at least three
different systems without finding the ideal solution. VI is the worst:
it requires a ^D to backspace over suggested indentation but ^H to
reteat indentation you've just typed. Emacs allows you to use ^H at all
times (I'm not talking of the various electric-C modes, which all too
often impose a particular, often uncomfortable, formatting style, but
about a normal auto-indent mode). A structured editor I've written
myself interprets a [return] with the cursor at the begin of a line
(after the indentation, that is) as a "dedent" operator. After a short
learning period this feels very pleasant, especially since you can
"dither" the return key: one return gives a new line, two returns in a
row give a dedented line. Unfortunately, this does not extend to
documents that may contain blank lines, or you'll need kludges like
typing a space followed a return to keep a blank line. Ideas, anyone?
--
Guido van Rossum, CWI, Amsterdam <guido@mcvax.uucp>
[Some context:]
In article <694@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes:
>In article <2642@hammer.TEK.COM> andrew@hammer.UUCP writes:
>>If you think it's easy to misplace a curly brace, you ain't seen
>>nothing until you go looking for the subtle program misbehavior caused
>>by incorrect indentation!
>
>True, and very important. Indentation is guaranteed to balance out by the
>end of the program. There's no such thing as an error, as far as the compiler
>can detect (except in a few cases where extra keywords like else appear).
>
>If you're using a regular text editor, using indentation can be very dangerous.
>As Mr. Klossner suggests, the correct suggestion is to use both closers and
>indentation, redundantly. Since the indentation supplies the visual cues,
>the closers should be unobtrusive, but present.cdshaw@alberta.UUCP (11/03/86)
In article <7125@boring.mcvax.UUCP> guido@boring.uucp (Guido van Rossum) writes: >The difference between misplaced braces bugs and misplaced indentation >bugs is that misplaced (often: missing) braces are hard to find. No they aren't. Use an editor which finds matching braces. They are common and very reliable. >On the other hand, misplaced indentation is immediately spotted by the >human reader, e.g. (using a language I am familiar with as example): > > PUT "" IN name > GET.CHAR c > WHILE 'a' <= c <= 'z': begin > WRITE c > PUT name^c IN name end > GET.CHAR c \ Bug! should be indented more > >Here, I would say, you notice the bug even while you are typing it, or >if not, you'll catch it immediately when you peruse the program again >after you find it gets stuck in an infinite loop. Thus, I find >indentation sufficient. Sure, but the begin/end pair (in lower case) makes it much more obvious because you have two visual cues. The whole point of indentation is communication with the HUMAN reader. The purpose of begin/end is for the machine. The combination of both is a definite plus. I have great difficulty with indentation-only simply because it is traditional that whitespace is meaningless, and it certainly seems far too easy to innocently delete whitespace and entirely change the program. Swapping begin/end for indentation simply make the compiler less able to catch bugs. Also, what about this: x := 4 ; for( i := 1 to 10 )do { x := 2*i; printf( "This is a debug line\n" ); y := 3 ; } The purpose of left-justifying the printf is so I can see it as garbage and remove it once the program works. My basic point is that indentation rules add the WRONG kind of "stiffness" to programming input. It requires you to be continually counting whitespace. All in all, while I can see the point of making the programmers job easier, it seems foolish to make everything easy simply for the writer's benefit. The point of a program is for others to read as well, so anything which makes the reading job harder is a clear lose. I don't believe that indentation alone is enough to adequately communicate the author's intention. > Guido van Rossum, CWI, Amsterdam <guido@mcvax.uucp> Chris Shaw cdshaw@alberta University of Alberta CatchPhrase: Bogus as HELL !
liberte@uiucdcsb.cs.uiuc.edu (11/04/86)
I rather like the editor that comes with Macintosh Pascal, and its sibling, Lightspeed Pascal from Think, Inc.. It allows character level editing but reformats whenever you hit ";" return or start a more distant modification. The reformating is syntax dependent but only changes the following text. Since the display is kept consistent, a complete reparse is not needed. This periodic reformating provides almost instant feedback as to whether your brackets match up since you, the human, can quickly tell whether the indentation is right. Even if the "end" is several pages after the "begin", you can see that your procedure doesnt end right, or whatever. The only problem is if you dont like how it indents. But you can turn off indenting if you want to go it alone. Dan LaLiberte liberte@b.cs.uiuc.edu liberte@uiuc.csnet ihnp4!uiucdcs!liberte
DMB@PSUVMA.BITNET (11/07/86)
Yes, i quite agree with you about Think's editor. One thing that would
really be nice is if you could collapse constructs into just the control
section (sort of like an outline processor). There's nothing worse then
scanning through a lot of comments and nonimportant (presently, anyway) to
find what your after
davelevy@ttrdc.UUCP (Daniel R. Levy) (11/07/86)
In article <108@pembina.alberta.UUCP>, cdshaw@alberta.UUCP writes: >In article <7125@boring.mcvax.UUCP> guido@boring.uucp (Guido van Rossum) writes: >>The difference between misplaced braces bugs and misplaced indentation >>bugs is that misplaced (often: missing) braces are hard to find. > >No they aren't. Use an editor which finds matching braces. They are >common and very reliable. >Chris Shaw cdshaw@alberta Ah, almost very reliable :-). Vi does this, but I had an awful time once with a fairly long C function (in someone else's code) which just would not compile on the machine I tried it on; kept getting strange error messages about bogus identifiers. Well, finally I idly put my cursor on the top curly brace of that function and hit '%'. Vi beeped at me! "HMMM, no match!" I said; "so that's why the code wouldn't compile!". Well, I went to the bottom of the code, put the cursor on the curly brace there, and hit '%' again. It matched with the second curly brace in from the top. I start moving in, matching pair against pair, for several iter- ations. Then '%' put me right in the middle of a printf statement: (void) printf("junkjunkjunk{trashtrashtrash\n"); ^ |-- see the "hidden" curly brace? Oh, well... *klunk* -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy
lat@druil.UUCP (TepperL) (11/07/86)
In article <1303@ttrdc.UUCP>, levy@ttrdc.UUCP writes: > Well, I went to the bottom of the code, put the cursor on the curly brace > there, and hit '%' again. It matched with the second curly brace in from > the top. I start moving in, matching pair against pair, for several iter- > ations. Then '%' put me right in the middle of a printf statement: > > (void) printf("junkjunkjunk{trashtrashtrash\n"); > ^ > |-- see the "hidden" curly brace? > > Oh, well... *klunk* There's any easy way around this. I've even used it before: (void) printf("junkjunkjunk{trashtrashtrash\n"); /* This } matches the one in the printf above. Vi is happy. */ -- Larry Tepper {ihnp4 | allegra}!drutx!druil!lat +1-303-538-1759