Third public review of X3J11 C

[Herman Rubin]

In article <8660 at ihlpb.ATT.COM>, nevin1 at ihlpb.ATT.COM (Liber) writes:
> In article <897 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
> |In article <4203 at adobe.COM>, burgett at steel.COM (Michael Burgett) writes:

 
> |That a badly designed language was rejected is irrelevant.

> But the part that isn't irrelevant is *why* did PL/1 turn out, in your
> words, to be a badly designed language?  We don't want to go around
> repeating the mistakes of the past if we don't have to.

A language should be easy to read and as easy to write as possible.  The
kludges made in PL/1 to allow the use of the properties of the machine were
to use the common assembler notation, which while it is precise, is difficult
to read and write.

HLLs such as C make heavy use of overloaded operators and infix notation for 
operators.  There are only a few assemblers which use infix notation, and I
know of none which use overloaded operators and weak typing.  In addition,
HLLs allow multiple operations in a single statement, array handling, and
similar goodies.

The makers of PL/1, when they came to allowing the user to use the low-level
procedures, required the users to use the clumsy assembler notation or even
worse.  I believe that a flexible HLL which comes close to accomplishing 
what both C and FORTRAN accomplish, and a lot more, can be produced.  It
might be necessary to require explicit operator precedence instead of implicit,
at least in some cases (it has been stated that this is one of the biggest
problems in a compiler; APL has completely dropped it), and possibly to 
remove some of the implicities introduced in some of the languages.

If there is a movement to produce a flexible HLL, I would be willing to
participate.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (Internet, bitnet, UUCP)