tneff@bfmny0.UU.NET (Tom Neff) (09/10/89)
Rather than rely on bureaucratic interpretation of a lengthy spec, why
not publish a portable Standard C compiler, written in K&R-1 C, which
exhibits the characteristics of a conforming compiler and is suitably
commented with references to the spec? The code generated could be
pseudocode or a suite of hardware specific generators could be assembled
as people have time to write them. Hotshot efficiency would not be
the goal -- leave that to the commercial vendors.
It seems to me that questions of "what do you do if X follows Y under
condition Z" would be a lot easier to deal with if the answer were
"whatever Standard C does" rather than "well what we MEANT to say in
paragraph 1.37.6 was..."
I suppose a meeting of the minds with Stallman on this is beyond hope...
--
Annex Canada now! We need the room, \) Tom Neff
and who's going to stop us. (\ tneff@bfmny0.UU.NEThenry@utzoo.uucp (Henry Spencer) (09/10/89)
In article <14646@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >Rather than rely on bureaucratic interpretation of a lengthy spec, why >not publish a portable Standard C compiler, written in K&R-1 C, which >exhibits the characteristics of a conforming compiler and is suitably >commented with references to the spec? ... >It seems to me that questions of "what do you do if X follows Y under >condition Z" would be a lot easier to deal with if the answer were >"whatever Standard C does" ... Unfortunately, what this amounts to is writing a new standard. It will be a much stricter one too, because there are a number of places in ANSI C where the author(s) will have to choose one specific approach. (For example, they will have to decide whether to use a tokenized or string-based preprocessor, and the effects of this decision *will* be visible.) This is guaranteed to make it unpopular with implementors who have taken different approaches, and their customers. It won't get anywhere near the level of acceptance that the current spec, warts and all, can expect. There is also the problem that you have to read the compiler to get answers to your questions. (Just experimenting with it won't do -- an experiment answers a question only for a specific program, and doesn't tell you how widely applicable the answer is.) Compilers tend to be a whole lot less readable than even ANSI standards. There is much to be said for expressing standards in formal notations, and much to be said for making formal notations executable, but C is not a very good notation for the job, because it forces decisions on too many low-level details that should be left open. And any formal notation has readability problems for anyone but the High Priests. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/10/89)
In article <14646@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >Rather than rely on bureaucratic interpretation of a lengthy spec, why >not publish a portable Standard C compiler, written in K&R-1 C, which >exhibits the characteristics of a conforming compiler and is suitably >commented with references to the spec? That's not viable -- at best you'd merely have one instance of a conforming implementation. There is enough flexibility allowed in implementing the spec that no single instance could serve as a yardstick against which others are measured. Besides, we tried that before (with PCC) and it just didn't work.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/10/89)
In article <1989Sep10.075346.1685@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >And any formal notation has readability problems for anyone but >the High Priests. It was proposed that the C language standard be expressed using a formal semantic specification language. The majority of the committee didn't wish to do that. Although it was before my time, I suspect that a major reason was the large amount of extra effort it would take for many members to come up to speed on the technique. However, by the end of the public review process, I'd become convinced that we probably would have been better off using a formal specification language. On the other hand, that in itself wouldn't have guaranteed a desirable C specification. C has too many "warts" to lend itself to a simple formal specification. It should be kept in mind when designing a brand-new programming language, though.
peter@ficc.uu.net (Peter da Silva) (09/10/89)
In article <14646@bfmny0.UU.NET>, tneff@bfmny0.UU.NET (Tom Neff) writes: > why not publish a portable Standard C compiler, written in K&R-1 C... > ...efficiency would not be the goal -- leave that to the commercial vendors. > It seems to me that questions ... [could be answerwed by] > "whatever Standard C does" Problem with this is that hotshot efficiency may require changing the semantics from what the Standard C Compiler does, while remaining within X3J11. Using a C compiler as the C standard was a bad idea when that compiler was K&R, and is a bad idea today. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "...the TV reporters, who are as intelligent as electric toasters" 'U` -- Clayton E. Cramer
scjones@sdrc.UUCP (Larry Jones) (09/11/89)
In article <11023@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > In article <1989Sep10.075346.1685@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > >And any formal notation has readability problems for anyone but > >the High Priests. > > It was proposed that the C language standard be expressed using > a formal semantic specification language. The majority of the > committee didn't wish to do that. Although it was before my time, > I suspect that a major reason was the large amount of extra effort > it would take for many members to come up to speed on the technique. Actually, there was more concern about those reading the standard. Since most of the committee members are compiler implementers, most of them were at least slightly familiar with at least some of the formalisms and didn't feel like it would be a major problem to become familiar enough with whatever got chosen to use it. (Besides, we were writing the standard, so we'd KNOW what it said, even if we couldn't understand it!) ;-) But nearly everyone wanted it to be of use to ordinary programmers as well as implementers, and there was some concern that not all implementers would take the effort to understand the formalism (think back to some of the supposedly C implementations that were available in '83). > However, by the end of the public review process, I'd become > convinced that we probably would have been better off using a > formal specification language. I wouldn't say I was convinced, but I had begun to seriously doubt the original decision (which I heartily endorsed at the time). ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@SDRC.UU.NET 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 "I have plenty of good sense. I just choose to ignore it." -Calvin
barmar@think.COM (Barry Margolin) (09/11/89)
In article <14646@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >It seems to me that questions of "what do you do if X follows Y under >condition Z" would be a lot easier to deal with if the answer were >"whatever Standard C does" rather than "well what we MEANT to say in >paragraph 1.37.6 was..." Until someone asks the question "what do you do if X follows Y under condition Z", NO ONE knows the intended answer, not even the implementor of Standard C. The whole point of the interpretations phase is to deal with ambiguities and omissions in the standard that weren't found during the drafting and review phases (no matter how hard you try, it's virtually impossible to make a complete language standard). Your proposal would cast in concrete any arbitrary or unintentional implementation decisions made by the Standard C implementor. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
hemphill@cit-vax.Caltech.Edu (Scott Hemphill) (09/15/89)
How does one go about obtaining a copy of the real ansi C standard? I don't want just a paraphrase. -- Scott Hemphill hemphill@csvax.caltech.edu ...!ames!elroy!cit-vax!hemphill