Newsgroups: comp.std.c Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: More thoughts on "Error Return" Message-ID: <1989Aug11.163551.15217@utzoo.uucp> Organization: U of Toronto Zoology References:<594@cybaswan.UUCP> <601@cybaswan.UUCP> Date: Fri, 11 Aug 89 16:35:51 GMT In article <601@cybaswan.UUCP> iiitsh@cybaswan.UUCP (Steve Hosgood) writes: >> Interested parties, note: the idea is *guaranteed* to go nowhere unless >> you are interested enough to implement it in a compiler. > >..yeah, but if you implement such a concept in a compiler, you've just put >an extension into it, and that would start to undo all the standards effort >straight away. I hate 'extended' languages - DEC and HP are my least favorite >language vendors for this very reason. It's all a bit 'chicken and egg' if >ANSI won't consider it until someone implements it. It is a sad fact that experimenting with extensions means experimenting with a non-standard language. You have to be convinced that it's worth it. (I personally don't see this as entirely a bad thing -- it cuts down on the number of frivolous experimental extensions. Note, "cuts down", as opposed to "eliminates".) But sane standards committees will indeed refuse to have anything to do with an idea if it has not been tried in an implementation. Language design is **MUCH** harder than it looks; the *only* way to be sure that some wonderful new feature does not interact unpleasantly with existing ones (and that it really is practical and useful) is to implement it and use it in real programming. (Note, not all standards committees are sane. X3J11 did pretty well, on the whole; they only had occasional moments of insanity. You can pretty much tell which moments those were, because the resulting features caught orders of magnitude more flak from the customers.) -- 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