Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!zehntel!dual!amd!decwrl!decvax!mcnc!ecsvax!bet From: bet@ecsvax.UUCP Newsgroups: net.lang.c Subject: aesthetics of C, and the ANSI standard Message-ID: <3054@ecsvax.UUCP> Date: Fri, 3-Aug-84 09:42:37 EDT Article-I.D.: ecsvax.3054 Posted: Fri Aug 3 09:42:37 1984 Date-Received: Sun, 5-Aug-84 06:21:43 EDT Lines: 37 In reference to the recent notes suggesting that the ANSI committee is screwing up badly, and we are going to have another ADA, what exactly are you complaining about? What I have heard here is that they aren't trying to make C different, they are attempting to define formally what it currently is, and tighten up existing fuzziness. In particular, what I have heard doesn't seem to violate the central spirit of C, which is a language sufficiently simple to be able to be implemented efficiently an almost any machine, and sufficiently expressive to be a powerful language. Comments? What have I missed? On an unrelated side-track: C has a concept of scope of names, and I think I understand that. Names can be local to a function, known throughout but local to an entire source file, or globally known across linking. Fine. Is there any concept of "name spaces" in C? It seems to me that these would often show up as an artifact of how a compiler is implemented, and would add a little bit to the cleanness of C. In particular, structure member names are, as far as the compiler is concerned, offsets. They are recognizable by the syntactic (or is it semantic?) surroundings -- that is name->member doesn't leave you suspecting that member might be a variable. Is there any reason why this shouldn't be allowed: struct node { int data; struct node *next; } main() { int data; } I can't see any potential for ambiguity here. Why should member names be forced to conflict with variable names? Bennett Todd ...{decvax,ihnp4,akgua}!mcnc!ecsvax!bet