Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.lang.c
Subject: Re: C subscripts
Message-ID: <5506@brl-tgr.ARPA>
Date: Mon, 29-Oct-84 21:09:08 EST
Article-I.D.: brl-tgr.5506
Posted: Mon Oct 29 21:09:08 1984
Date-Received: Wed, 31-Oct-84 01:18:05 EST
References: <195@mouton.UUCP>
Organization: Ballistic Research Lab
Lines: 44

> Who else out there thinks that
> 	some_array_name[more][long][names]
> is actually a good way to do things?

I do.  There is a deeper meaning to C arrays than to Fortran arrays.

> Just as we need nested comments, because after all other "great languages"
> do, I propose that C support "normal" subscripting.

We DON'T need nested comments.  I brought up the issue solely because I
was getting bored and wanted a new topic for discussion.

> Mathematicians have been around longer than C; Fortran too;
> so, in the name of compatability, which is what the ANSI standard
> is all about anyway, the compiler SHOULD accept 
> 	some_array_name[more,long,names]

Most mathematicians seldom write subscripts that way!
C is not FORTRAN.  Why should it worry about "compatibility" of appearance?

> I would also propose one small, new, preprocessor built-in,
> 	SUBTYPE  which would be defined OLD or NEW
> as in 
> 	#if SUBTYPE == OLD
> 		fprintf(stder, "buy a new compiler");
> so programmers know what's going on.

This is exactly the sort of thing we DON'T want in the new standard.

> Now, BEFROE the flames start I KNOW the comma operator exists.
> This is not overloading because subscripts are expressions, not statements.
> So don't start quoting K&R pg 192 to me.

You're right that it's not overloading.  What it is, is AMBIGUOUS.

	type	data[M][N];	/* or as you wish, [M,N] (also ambiguous) */
	data[i];		/* unambiguously a pointer to (type) */
	data[i][j];		/* unambiguously a (type) */
	data[i,j];		/* under existing rules, a pointer to (type);
				   under your proposal, AMBIGUOUS */

Arrays are definitely second-class citizens in C; pointers are full citizens.
I hope the ANSI C committee cleans this up, but leaving [][] syntax intact
seems essential.