Path: utzoo!utgpu!attcan!uunet!husc6!rutgers!joyce!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: "for" loops in C ...
Message-ID: <654@quintus.UUCP>
Date: 10 Nov 88 07:49:51 GMT
References: <867@cernvax.UUCP> <1811@garth.UUCP>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 30

In article <1811@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes:
>>personally, IMHO, would be happy with a[next] for structure access or
>>a.i for array access.  Isn't it all really the same and just a matter
>
>How would you parse that? Fields and subscripts have different syntax,
>although the concept are similar, to make context-free parsing possible.

Some languages use different syntax for fields and arrays, just as
some languages (e.g. C, Pascal, Algol) use different syntax for arrays
and other functions and some (e.g. Fortran, ADA) don't.  Context-free
parsing has nothing to do with the case.  In the usual mathematical
model of records, "fields" are projection FUNCTIONS.  That is, given
	type node = (data: int, next: link)
we have two functions data: node->int, next: node->link.  And an array
is a function which maps its index set to its element set, e.g.
	var data: array[node] of int;
	    next: array[node] of link;
Whether one writes
	n.data		"field"
	data[n]		"array"
	data(n)		"function"
is a matter of taste.  You have to check "data" in the symbol table anyway,
to make sure that it is a valid field name (or array name, or function
name).  Some people like to think of fields, arrays, and functions as
distinct, and prefer a notation which makes that explicit.  Some people
like to think of them all as functions, and prefer a notation which lets
them change the implementation without having to rewrite all their code.

Have you never found it frustrating that C will let you write macros that
look like functions, but not macros that look like arrays or fields?