Path: utzoo!attcan!uunet!husc6!ogccse!blake!uw-beaver!cornell!mailrus!ames!oliveb!Ozona!chase
From: chase@Ozona.orc.olivetti.com (David Chase)
Newsgroups: comp.lang.c
Subject: Optional semi-colons
Summary: It's a solved problem; check your history books.
Message-ID: <41117@oliveb.olivetti.com>
Date: 28 Apr 89 00:17:21 GMT
References: <9244@alice.UUCP> <12716@lanl.gov> <10134@smoke.BRL.MIL>
Sender: news@oliveb.olivetti.com
Reply-To: chase@Ozona.UUCP (David Chase)
Organization: Olivetti Research Center, Menlo Park, CA
Lines: 41

In article <12716@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>Yes. For example, why does C treat a carriage return as whitespace?
>Nobody programs like that.  Most people put _one_ statement per line,
>so the use of _both_ semicolon and carriage return as statement terminators
>seems redundant.  Why does C choose to ignore the "wrong" one?

In article <10134@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>Many programming environments work best when source file line lengths
>are limited, typically to no more than 80 characters (the exact useful
>limit varies).  ...  Therefore, allowing simple statements to span
>multiple lines is a practical convenience for the programmer.

I don't think that's a very good answer, because:

It's a solved problem, and it was solved before C was around.  I've
programmed a good bit in such a language, and found that it worked
quite well.  To quote [Richards & Whitby-Strevens]:

  BCPL programs are written in free format.  You can put several
  statements on a single line, or use several lines for a single
  statement.  Semicolons must be used to separate statements on a
  single line to resolve ambiguity and can also be included for
  greater clarity.  `end of line' has the effect of terminating a
  statement if syntactically this is possible.  So if you want to
  split a statement over two lines, then the split may be at any
  point where the statement could not be terminated, for example
  after a + or -.

I should also note that the systems on which I used BCPL were of the
dreaded fixed-line-length variety.  It was, in fact, the language of
choice for me (over Fortran, Pascal, and PL/1) on these systems,
though its lack of a type system sometimes made life interesting.

This just makes the "why does C do it the other way" question more
curious; the only explanation that comes to mind is that it makes it
easier to write programs that generate programs (lex and yacc, e.g.).
Of course, hacking around the output to ensure non-ambiguity is not
too hard, especially when compared with the other problems solved by
these programs (besides, there's always filters, right?).

David