Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxj!mhuxr!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!tgr!Schauble@MIT-MULTICS.ARPA From: Paul SchaubleNewsgroups: net.lang.c Subject: Multilevel standards Message-ID: <6832@brl-tgr.ARPA> Date: Sat, 29-Dec-84 02:31:09 EST Article-I.D.: brl-tgr.6832 Posted: Sat Dec 29 02:31:09 1984 Date-Received: Sun, 30-Dec-84 02:59:44 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 63 Reply to Hokey at GANG.UUCP I appreciate the comments. I wish I knew more about ANSI X11.1, because I think I don't quite understand the idea behing "Standard Optional Language Extensions". How are these different from the COBOL Multi-Level modules? I agree that multi-level standards can be undesirable. But there is a real problem here. "Standard" Pascal describes a mimimum language. So minimum that it is not usable. I probably shouldn't claim that there are no production quality standard Pascal implementations, but I don't know of one and have never used one. Because the standard is so mimimal, every implementation extends the language to make it usable. Because there is no standard for these extensions, they are all different. As a result, programs are not portable and the standard is relatively useless. Can we avoid this trap with C?? The other piece of this problem is in K&R itself. Look at the page opposite the CONTENTS page, where is says "Copyright 1978 by Bell...". This book is almost seven years old!! Has the language changed in the meantime? Certainly. Not being a Unix person, can I find out how? Where is the widely distributed and readliy available book that describes the current language?? Ladies and Gentlemen of the standards committee, I suggest that you should be writing that document.nn Consider this: during the three working days of this past week I tried to move two C programs from Unix (vintage unknown) to an IBMPC using a recent version of Computer Innovation C86. Both failed, one because the programmer assumed that structure element names were tied to the structure rather than global and the other because it TYPEDEF'ed a structure and then assumed it could be returned by a function. Both of these features exist on current (for some values of current) Unix compilers. Which ones? What other features are out there that are going to bite me next week or the week after? I look to a language standard to help solve these problems. What help is a standard that simply declares all of these compiler to be standard? And that is the problem I see facing the standard committee. If you formalize K&R, perhaps with some minor updates, you will freeze a snapshot of the language that is already badly out of date. This will be useless to a significant part of the language users. If you make more than trivial updates, you will omit a lot of current compilers and cause political problems. I see the source of the problem being that there really are two families of compilers in this world: those following K&R and those following the recent Unix compilers. You really do need two different standard, or two different levels. As an aside, I was very involved in Cobol work for a major manufacturer at about the time the multi level standard became official. This standard forced a lot of manufacturers to upgrade their compilers, not because the standard required it, but because being standard to a lower level was a sales disadvantage and because having the higher level defined told the management exactly what was needed to fix the problem. I strongly believe that the best way to cause improvements in the state of the art is to make a two level standard and let market forces work on those on the lower level. Paul