Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!seismo!nbires!hao!hplabs!tektronix!uw-beaver!uw-june!entropy!dataio!bright
From: bright@dataio.UUCP (Walter Bright)
Newsgroups: net.lang
Subject: Re: re: compound statements
Message-ID: <1036@dataio.UUCP>
Date: Tue, 8-Jul-86 12:45:40 EDT
Article-I.D.: dataio.1036
Posted: Tue Jul  8 12:45:40 1986
Date-Received: Fri, 11-Jul-86 06:25:13 EDT
References: <5287@topaz.RUTGERS.EDU>
Reply-To: bright@dataio.UUCP (Walter Bright
Organization: Data I/O Corp., Redmond WA
Lines: 17

In article <5287@topaz.RUTGERS.EDU> gaynor@topaz.RUTGERS.EDU (Silver) writes:
>!!Simpler parsing methods is *NO*EXCUSE* for compromising a language!!
>May you someday be forced to program in microcode (knock on wood :-).
>I'm sure many compiler schemes would surely handle the removal of this
>restriction no problem.  Especially those that are generated by a
>compiler generator.

Ah, but hard-to-understand languages are also hard-to-parse. There is a
direct correlation. I have designed a computer language (ABEL), and
wrote the parser for it at the same time. Whenever I ran into trouble
with the parser, I changed the language. The result is a simple to parse
language, however, I did not sacrifice any features.

The C language is difficult to parse (like the declarations), and just those
constructs which are difficult to parse are also difficult to understand.
C could be made much easier to parse without sacrificing any of its features
(but of course it wouldn't be C anymore...).