Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: net.lang.c
Subject: Re: What should be added to C
Message-ID: <1518@mmintl.UUCP>
Date: Fri, 30-May-86 10:02:40 EDT
Article-I.D.: mmintl.1518
Posted: Fri May 30 10:02:40 1986
Date-Received: Sun, 1-Jun-86 08:36:39 EDT
References: <1462@mmintl.UUCP> <5498@alice.uUCp> <1497@mmintl.UUCP> <450@cad.BERKELEY.EDU>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT
Lines: 53

In article <450@cad.BERKELEY.EDU> faustus@cad.UUCP writes:
[Concerning andif]
>I think this looks cleaner, but in any case it isn't an often-encountered
>situation and the semantics aren't obvious.

There is no disputing matters of taste.  I find it is an often-encountered
situation, and that the semantics are obvious.

>You can write arbitrarily large macros by putting backslashes at the end of
>lines.  This is ugly but it works.

This doesn't let you use "#if" in the body of the macro, as my example would
require.  To fully explicate, my example would be:

#begdef copy(to, from, number)
#if sizeof(from) % WORD_SIZE == 0
   copyword(to, from, number * sizeof(from) / WORD_SIZE)
#else
   strncpy(to, from, number * sizeof(from))
#endif
#enddef

> > Confusing "=" and "==" in if statements is a common mistake.  If "=" is not
> > a legal operator, this error becomes very rare.
>
>It's also an extra character to type.  If you are prone to this sort of
>error, just run your code through grep if | grep = | grep -v == ...

Thanks but no thanks.  If one added a separate step to the compilation
process for each type of relatively common error, nothing would ever get
done.  Again, please note that I did not propose outlawing "=" as a
default -- you would have to specify an option to exclude it.

> > This is the whole point of having a standard.  It gives you some assurance
> > that compilers which use the features will be available.
>
>If the standard has all the things you enumerate, not many people will follow
>it and it will be worse than no standard at all.

This is not consistent with the experience in promulgating standards for
other languages.  FORTRAN 77 differs from the old standard rather more than
the relatively modest set of changes I proposed; it has been widely adopted,
essentially all new FORTRAN compilers adhere to the standard, and such
compilers have been made available for most machines still in use on which
an older compiler is available.

Again, I want to emphasize that my proposals are not things to be included
in the current standard (X3J11), but the next one.  It is both too late to
include changes of this magnitude in that standard, and inappropriate to
make this kind of change in the initial standardization of the language.

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Multimate International    52 Oakland Ave North    E. Hartford, CT 06108