ralphw@mit-eddie.UUCP (Ralph W. Hyre) (04/11/85)
Has anyone though of trying to see what would happen to modula-2 syntax if semicolons were optional, as in CLU? (CLU is a stongly typed language developed at MIT from 1974 to 1978, more or less the same period when Modula-2 was being developed. CLU is designed to support data abstraction and modularity, and achieves this through the mechanism of CLUsters, which roughly correspond to Wirth's modules. (Clu stores all objects on a heap, so the programmer isn't burdened with storage allocation responsibilities.) I just seems strange that one language (CLU) would not require explicit terminators but another (Modula-2) would. After all, compilers can be made smart enough to allow humans to type fewer superfluous symbols. - Ralph
sasaki@harvard.ARPA (Marty Sasaki) (04/12/85)
I'm fed up with semi-colons too. Way back in the late 1960's BCPL
compilers were putting in semi-colons for you. The rules were simple,
and if you blindly left semi-colons out and formatted your text in a
funny way, you would sometimes get errors.
I have a modula pre-processor in the works which will do simple macro
expansion (like C), include processing, and semi-colon insertion. If
I ever get it done, I'll post it, since it really is very small (so far).
--
----------------
Marty Sasaki net: sasaki@harvard.{arpa,uucp}
Havard University Science Center phone: 617-495-1270
One Oxford Street
Cambridge, MA 02138gary@bocklin.UUCP (04/12/85)
> Has anyone though of trying to see what would happen to Modula-2 syntax if > semicolons were optional, as in CLU? > ... > It just seems strange that one language (CLU) would not require explicit > terminators but another (Modula-2) would. After all, compilers can be > made smart enough to allow humans to type fewer superfluous symbols. > - Ralph Beware the ``superfluous'' claim. It has gotten us such wonders as the ``='' vs ``=='' problems in C. Certainly it is possible to make semicolons optional, but it has had strange side-effects, in the past. In an early version of Icon (I have not checked the problem recently), the code segment a:= ( ... very long expression ... ) + (another long expression) ; was treated as *two* statements. (Expressions really. Icon, like C, is an expression language.) ``a'' was assigned the value of the first expression and the second value was thrown away. After tearing hair, I finally figured out the problem and tried a:= ( ( ... very long expression ... ) + (another long expression) ); expecting the extra parentheses to make the expression one. Instead I got a syntax error complaining about the missing right parenthesis before the ``optional'' semicolon at the end of the first line, and a second error about the extra right parenthesis on the second line. The correct ``fix'' was to write a:= ( ... very long expression ... ) + (another long expression) ; The compiler was smart enough to know that ``optional'' semicolons don't follow operators. The real problem was that I couldn't get a good explanation of when ``optional'' semicolons would be inserted. It certainly didn't save me any work that day. Notice that I wasn't even making use of the feature. -- Gary Levin / Dept of CS / U of AZ / Tucson, AZ 85721 / (602) 621-4231
jack@boring.UUCP (04/12/85)
I have written some fairly large programs in BCPL (one of
the very remote predecessors to C), which has the feature that
a semicolon before end of line can usually be ommitted.
When you first look at it, it seems like a great idea.
But..... I never used it. Being used to pascal and C typing
a semicolon before eoln goes automatic (at least, to me).
When I looked at my programs lateron, I noticed that the first
few didn't have semicolons, but that I started adding them
again as soon as I didn't think of it.
Also, as another argument: semicolons provide a bit of
redundency, and redundancy is always nice, since it helps
you detect errors at compile time, in stead of at runtime.
If a feature decreases my typing-time by 10% and increaes
debugging time by 10%, I don't want the feature.
--
Jack Jansen, {decvax|philabs|seismo}!mcvax!jack
The shell is my oyster.bright@dataio.UUCP (Walter Bright) (04/15/85)
Semicolons are a very useful redundancy in the language. The reduncancy makes error detection and recovery easier in the compiler. With C, at least, one would have to make a newline a statement terminator, or else one could have: a = 5 *p++ parsed as a=5; *p++; or as a=(5 * p++); If a newline was made a statement terminator, then multi-line statements would be a problem. All in all, for a free-format language, an explicit termination character is nice.
wall@decwrl.UUCP (David Wall) (04/17/85)
Jack Jansen writes: > Also, as another argument: semicolons provide a bit of > redundency, and redundancy is always nice, since it helps > you detect errors at compile time, in stead of at runtime. > If a feature decreases my typing-time by 10% and increaes > debugging time by 10%, I don't want the feature. I don't mind semicolons myself, but don't get the impression that they turn runtime errors into compile-time errors, at least not in keyword-including statement-oriented strongly-typed languages like Modula-2. The Modula-2 grammar is perfectly unambiguous without the semicolons. One thing that having semicolons does, though, is allow the parser to recover from syntax errors quicker, so you can get a greater number and proportion of correct compile-time errors in a single compilation. This is not a benefit to be sneezed at.
asente@Cascade.ARPA (04/18/85)
...!bocklin!gary says: > In an early version of Icon (I have not checked the problem recently), > the code segment > > a:= ( ... very long expression ... ) > + (another long expression) ; > > was treated as *two* statements. (Expressions really. Icon, like C, > is an expression language.) ``a'' was assigned the value of the first > expression and the second value was thrown away. . . . > The correct ``fix'' was to write > > a:= ( ... very long expression ... ) + > (another long expression) ; > > The compiler was smart enough to know that ``optional'' semicolons > don't follow operators. The real problem was that I couldn't get a > good explanation of when ``optional'' semicolons would be inserted. This seems to stem from a misunderstanding of the meaning of the semicolon in Icon. The end of line is the statement terminator, not the semicolon. Continuation is provided by ending the line to be continued so that it is not a complete statement; so you have to say a := b + c rather than a := b + c . Or, for another example, you have to say if (condition) then statement rather than if (condition) then statement which is a null statement after the condition. Several people have stated that semicolon terminators add redundancy to a language. This is false! There is no redundancy since the end-of-line is ignored completely in languages like C. The only real purpose for semicolons, as far as I can see, is so that lazy compiler writers don't have to work as hard to do error recovery. -paul asente asente@cascade.ARPA ...decwrl!glacier!cascade!asente
jww@bonnie.UUCP (Joel West) (04/20/85)
There is no conceivable reason why semicolons arenecessary to implement any higher-level language. HOWEVER.... If you don't have semicolons, you get a very slow parser that does lots of backups to figure out what really comprises a statement You get very cryptic and meaningless error messages with many syntax errors; There are potential ambiguities in the syntax, particularly in conjunction with other "optional" features. In short, there ain't no such thing as a free lunch (TANSTAAFL). I have the joy of maintaining a compiler for a language where semicolons are not used at all, and statement boundaries are completely ignored (except an EOL is disallowed in a literal). The lack of an explicit boundary meant in one real case that the statements CLOSE xyz PRINT ... was ambiguousy, since "PRINT" was a valid "CLOSE" option. Making a comma operator mandatory removed this, since "CLOSE xyz, PRINT" is different from "CLOSE xyz [;] PRINT" -- Joel West (619) 457-9681 CACI, Inc. - Federal 3344 N. Torrey Pines Ct La Jolla 92037 jww@bonnie.UUCP (ihnp4!bonnie!jww) westjw@nosc.ARPA "The best is the enemy of the good" - A. Mullarney