[net.lang.c] C names

shawn@mit-eddie.UUCP (Shawn McKay) (05/21/85)

If you wish to make such large changes, why don't you change the name
of the language? What berkeley folks use IS NOT C as is documented
by the K&R book. Which I would expect to be the ONLY reasonable standard
to be used to define the 'C programming language'. Perhaps it's time
for the 'D' programming language. I'll leave out what I think D should
stand for.

			Yours In Hacking,
			  -- Shawn
p.s.:
Flamers reply at own risk.

Uucp: mit-eddie!shawn
Arpa: Shawn at Mit-Mc

jqj@cornell.UUCP (J Q Johnson) (05/22/85)

What is C?  K&R?  Harbison&Steele?  The ANSI standard?

	From: shawn@mit-eddie.UUCP (Shawn McKay)
	Subject: C names
	Date: 21 May 85 19:43:52 GMT

	... why don't you change the name
	of the language? What berkeley folks use IS NOT C as is documented
	by the K&R book.

Neither, of course, is any other commonly used C implementation.

Seems to me we've been over this ground too often before.

gwyn@Brl.ARPA (VLD/VMB) (05/23/85)

Hey, there is considerable expert agreement that C as described in
K&R is in need of updating.  That is what the ANSI X3J11 committee
was formed for.  Indications are that the eventual ANSI standard C
will include long variable names (unique in every character),
limited only insofar as they are used for externs and so have to
satisfy existing Fortran-oriented link editors.

It is true, though, that for portability across the widest range
of EXISTING C compilers, code should not rely on flexnames.

lwall@sdcrdcf.UUCP (Larry Wall) (05/24/85)

In article <4316@mit-eddie.UUCP> shawn@mit-eddie.UUCP (Shawn McKay) writes:
>
>If you wish to make such large changes, why don't you change the name
>of the language? What berkeley folks use IS NOT C as is documented
>by the K&R book....

Most C's don't correspond to the K&R book.  "C" stands for confusion.

>    ...Which I would expect to be the ONLY reasonable standard
>to be used to define the 'C programming language'...

I presume this means you will repudiate the new C standard when it comes
out shortly.

>                                                  ...Perhaps it's time
>for the 'D' programming language. I'll leave out what I think D should
>stand for.

D for development...E for evolution...F for forward...G for good...

(Actually, a good case can be made that the next language should be
P, for progress.)

Pretty soon we'll wrap around and have A for Ada.  What fun!

Give me progress AND give me standards...
Give me liberty AND give me death...
Give me...

Never mind, I'm in a strange mood today.  For instance:

> Flamers reply at own risk.

Owners at risk reply flame.

Hmm, that almost means something.  Must be Friday.
Larry Wall
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall

rcj@burl.UUCP (R. Curtis Jackson) (05/24/85)

> What is C?  K&R?  Harbison&Steele?  The ANSI standard?
> 
> 	From: shawn@mit-eddie.UUCP (Shawn McKay)
> 	Subject: C names
> 	Date: 21 May 85 19:43:52 GMT
> 
> 	... why don't you change the name
> 	of the language? What berkeley folks use IS NOT C as is documented
> 	by the K&R book.
> 
> Neither, of course, is any other commonly used C implementation.
> 
> Seems to me we've been over this ground too often before.

I just came back from C-day at Murray Hill yesterday, and many
of my fears about the new ANSI standardization have been allayed;
they've stuck very closely to K&R in most respects.  More I cannot
say because of proprietary rules (I don't know how much of the day
was proprietary but I'll feel better assuming it was all such).

I'm hoping that the ANSI standard will be adopted without a lot of
fuss - it'll be nice to have a (good) standard.
-- 

The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson	...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj
			...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj

guy@sun.uucp (Guy Harris) (05/27/85)

> I just came back from C-day at Murray Hill yesterday, and many
> of my fears about the new ANSI standardization have been allayed;
> they've stuck very closely to K&R in most respects.  More I cannot
> say because of proprietary rules (I don't know how much of the day
> was proprietary but I'll feel better assuming it was all such).

Proprietary rules?  AT&T is more paranoid that I thought.  The ANSI C
standard is 100% non-proprietary; AT&T's plans for ANSI C compatibility may
be proprietary, but the degree to which ANSI C is or isn't like K&R is
public information.

	Guy Harris