jagardner@watmath.waterloo.edu (Jim Gardner) (02/10/89)
In article <9621@smoke.BRL.MIL> Gwyn@BRL.MIL (Doug Gwyn (VLD/VMB)) writes: >Note also that the "pascal" keyword of APW C should be changed to >something like _pascal_ and then for compatibility the APW-specific Shouldn't that be __pascal, or _Pascal? Or has ANSI decided to simplify the reserved identifier rules as an editorial change.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/11/89)
In article <23551@watmath.waterloo.edu> jagardner@watmath.waterloo.edu (Jim Gardner) writes: >In article <9621@smoke.BRL.MIL> Gwyn@BRL.MIL (Doug Gwyn (VLD/VMB)) writes: >>Note also that the "pascal" keyword of APW C should be changed to >>something like _pascal_ and then for compatibility the APW-specific >Shouldn't that be __pascal, or _Pascal? Or has ANSI decided to simplify >the reserved identifier rules as an editorial change. My copy of the proposed standard is buried as a result of moving to a new office, so I couldn't look this up. Thus the "something like". Of course I recommend following the actual standard specification.
glasser@madnix.UUCP (Daniel Glasser) (02/12/89)
Since I became indirectly involved in the ANSI C debate (several years ago) I've objected to the combination of the language standard with the library standard into one document. The ANSI document allows two different types of implementations to call themselves "standard" -- hosted and non-hosted. A hosted implementation requires all of the library routines as they appear in the standard, a non-hosted implementation does not. In both cases, the syntax and semantics of the language itself are identical. I'm not saying that there should not be a standard for the library, just that it should be its own standard. There are some environments where the full-blown standard library is inappropriate or impossible. Also, compiler writers are not always the best library writers. With the advent of common object file format standards, libraries may be purchased from vendors other than the compiler vendor, but if that library does not conform to the ANSI standard, the compiler is called non-conformant. I'm babbling, but I think the above expresses my views. -- ------------------------------------------------------------------------------- Daniel A. Glasser -- One of those things that goes "BUMP! (ouch)" in the night. glasser@madnix or ...!uwvax.wisc.edu!per2!dag or ...!uwvax.wisc.edu!persoft!dag
daveb@geaclib.UUCP (David Collier-Brown) (02/12/89)
At some point the compiler-writers are going to have to start thinking about known (often partial) solutions to the namespace pollution problems of simple languages like C. (and PL/1, lest anyone think I'm being snarky with the use of "simple"). Several of these are 1) making unnecessary names disappear a) the C "static" keyword b) the Multics "binder" 2) making all names unique a) class.element or class_$element b) user-defined prefixes c) name: composed: out: of: whole: calling: sequence: 3) explicit namespace-selection a) with x; use x b) invoke x c) import x from y 4) controlled vocabulary a) the following 5280 words are reserved... I recommend against the last. Considering the origins of C, I'd suggest re-raising the idea of a binder once again. I once wrote one for a linker which produced almost-ready-to-run code, and found that all I had to do was remove external-symbol records... --dave (I thought it was elegant. My boss KNEW I was lazy) c-b -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | He's so smart he's dumb. Mississauga, Ontario | --Joyce C-B
leichter@cs.yale.edu (Jerry Leichter) (02/14/89)
In article <3669@geaclib.UUCP>, daveb@geaclib.UUCP (David Collier-Brown) writes... > > At some point the compiler-writers are going to have to start >thinking about known (often partial) solutions to the namespace >pollution problems of simple languages like C. (and PL/1, lest >anyone think I'm being snarky with the use of "simple"). > Several of these are > ... > 4) controlled vocabulary > a) the following 5280 words are reserved... > ... PL/I has its share of problems, but one it has NEVER had is namespace pollu- tion. There are NO reserved words in PL/I! Even such bizarre constructs as: IF IF = THEN THEN ELSE = ELSE ELSE THEN = IF are perfectly legal. Having no reserved words was an explicit goal of the original designers. They knew that they were designing a large language, which was supposed to address a very broad spectrum of programmers. They also had experience with COBOL, which has perhaps the longest list of reserved words of any extant language. (Well, if you count in all the "reserved" things in the library, ANSI C in a hosted environment is now a strong competitor!) They considered it unreason- able to require a programmer to know all the reserved words, even those used for features of the language he had no interest in and knew nothing about. Doing without reserved words requires some extra care in designing the grammer of your language, but it can be done. (Years ago, I remember seeing an arti- cle somewhere, probably in SIGPLAN Notices, showing how to translate any grammar WITH reserved words into one WITHOUT, or point out where the ambigui- ties arise. I've never been able to find it, though.) That most people are not aware of this feature of PL/I is testimony to the fact that it is possible for the resulting grammar to be quite natural. -- Jerry
henry@utzoo.uucp (Henry Spencer) (02/14/89)
In article <490@madnix.UUCP> glasser@madnix.UUCP (Daniel Glasser) writes: >I'm not saying that there should not be a standard for the library, just >that it should be its own standard. Why? For most applications the two go together anyway -- C is rather more dependent on its library than a lot of other languages. >There are some environments where the full-blown standard library is >inappropriate or impossible... Hence the provisions for "non-hosted" implementations. >... With the advent of common object file format >standards, libraries may be purchased from vendors other than the >compiler vendor... Ho ho ha ha ho ho. At present there is roughly one "common object file format" per machine, although there are some small signs of progress. Don't forget that you need common calling conventions and common system- call conventions as well. Also, a really good library is tied in with the compiler, since things like memcpy() are best implemented by the compiler, not as normal library functions. -- The Earth is our mother; | Henry Spencer at U of Toronto Zoology our nine months are up. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (02/14/89)
In article <50499@yale-celray.yale.UUCP> leichter@cs.yale.edu (Jerry Leichter) writes: >... There are NO reserved words in PL/I! ... That most people are >not aware of this feature of PL/I is testimony to the fact that it is possible >for the resulting grammar to be quite natural. Or to the fact that many PL/I compilers *do* have reserved words, i.e. they do not implement the full language. (In fact, has there ever been a PL/I compiler that implemented the *entire* language?) -- The Earth is our mother; | Henry Spencer at U of Toronto Zoology our nine months are up. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
nick@ccicpg.UUCP (Nick Crossley) (02/15/89)
In article <50499@yale-celray.yale.UUCP> leichter@cs.yale.edu (Jerry Leichter) writes: >...They also had experience with COBOL, >which has perhaps the longest list of reserved words of any extant language. >(Well, if you count in all the "reserved" things in the library, ANSI C in a >hosted environment is now a strong competitor!)... Surely, with the reservation of all 'isxxx', 'toxxx', 'strxxx', etc., words for future use, ANSI C is easily the winner. Let's see; 'is' followed by a lower case letter (36 possibilities), followed by up to 3 more characters, each of which is an upper or lower case letter or a digit or an underscore = 26 + 26*83 + 26*83*83 + 26*83*83*83 = 15047760! Macro names can, I believe, be up to 31 characters, so the <errno.h> Exxx names have E(uppercase letter or digit)(up to 29 letters or digits or _), which gives a number somewhere around 1e57!! Note that these names are reserved whether or not any headers are included (or at least the external names are; the draft seems to imply by this that the Exxx macro names are not reserved unless you include <errno.h>). This is based on the May 13th draft; I do not expect this has changed since then. Do any actual or proposed compiler/lint implementations give warnings when one of these 'reserved for future use' identifiers is used? -- <<< standard disclaimers >>> Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA. (714) 458-7282 uunet!ccicpg!nick / nick@ccicpg.UUCP
daveb@geaclib.UUCP (David Collier-Brown) (02/15/89)
> In article <3669@geaclib.UUCP>, daveb@geaclib.UUCP (David Collier-Brown) writes... >> At some point the compiler-writers are going to have to start >>thinking about known (often partial) solutions to the namespace >>pollution problems of simple languages like C. (and PL/1, lest >>anyone think I'm being snarky with the use of "simple"). >> Several of these are >> ... >> 4) controlled vocabulary >> a) the following 5280 words are reserved... From article <50499@yale-celray.yale.UUCP>, by leichter@cs.yale.edu (Jerry Leichter): > PL/I has its share of problems, but one it has NEVER had is namespace pollu- > tion. There are NO reserved words in PL/I! Agreed wholeheartedly! I should probably add 4b) No reserved words and suggest its achievement by selective initiation, as done in Multics Pl/1 (which, on reflection, sounds like a sufficent tool when used with a binder to achieve our main end...) --dave (I occasionally describe C as PL/1 after a very harsh editor said "Too many words! Take some out.") c-b -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | He's so smart he's dumb. Mississauga, Ontario | --Joyce C-B