Paul Schauble <Schauble@MIT-MULTICS.ARPA> (12/29/84)
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.
Paulhenry@utzoo.UUCP (Henry Spencer) (01/02/85)
> ... "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 problem with Pascal was that the original language was excessively minimal. We *have* avoided this trap with C, since it was in heavy use for production work long before K&R, much less the current ANSI effort. > 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? Much less than you think, actually. A few small additions, virtually no incompatible changes. C has been very stable; the age of K&R really does not show all that much. > [various] 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? Don't sweat it. The ANSI standard is *not* going to do this. In fact, I'm not aware of *any* language standard that has ever done this. > 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 have no doubt that there were political problems, but it would appear that they were faced and solved. The ANSI standard is going to be, very roughly speaking, that of the very latest Unix compilers, plus some odds and ends. The result is significantly larger than K&R, and is likely to make all existing compilers obsolete to some degree. Since the committee includes representatives from most of the major compiler producers, it would appear that this has been accepted by the people who will be hurt by it. (If you will be hurt by it and you weren't on the committee, why weren't you? ANSI committees are open to anyone willing to make the investment in time and travel.) > 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. Even better, if you can get away with it, is to make a one-level standard which omits the lower level completely. This is what we're getting for C. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jc@mit-athena.ARPA (John Chambers) (01/04/85)
> > ... "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 problem with Pascal was that the original language was excessively > minimal. We *have* avoided this trap with C, since it was in heavy use > for production work long before K&R, much less the current ANSI effort. Hey, c/mon fellas! Pascal was designed as an introductory language for a first programming course. Of course, it's restricted! A full system language (like C) is not appropriate for Programming 101. A toy language (like Pascal) is not appropriate for building operating systems. If you're going to heap scorn, it's more appropriate to heap it on the people who insist on using the wrong tool for the job. I mean, a bicycle is an atrocious tool for hauling coal cross-country; a locomotive is an atrocious tool for riding along paths in the park. That doesn't mean either is an atrocious tool; it just means you've chosen the wrong one for the job. What am I doing flaming on this topic? It won't do any good. Oh well, on to the next article. John Chambers
brad@gcc-opus.ARPA (Brad Parker) (01/07/85)
In article <11@mit-athena.ARPA> jc@mit-athena.ARPA (John Chambers) writes: > >Hey, c/mon fellas! Pascal was designed as an introductory language for >a first programming course. Of course, it's restricted! A full system >language (like C) is not appropriate for Programming 101. A toy language >(like Pascal) is not appropriate for building operating systems. > John Chambers Ah John, perhaps you should have a short talk with the folks over at Apollo. They built an entire os, a transparent shared file system, network and graphics system using Pascal. It has dynamic runtime binding (unlike unix) and shared runtime libraries (unlike unix). The system is not shabby - it's real fast AND supports C. Not bad for a "toy language". (personally, I would have done the work in C, but it shows that that vehicle is not the only concideration, the destination is...) -- J Bradford Parker uucp: seismo!harvard!gcc-opus!brad otherwise: what else is there ? "Say something once, Why say it again ?" - David Burne
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/07/85)
So far as I know, every place that has used Pascal for significant systems programming has found it necessary to extend the language beyond standard Pascal in order to remedy some of the language's basic deficiencies. The biggest lossage in Pascal about which nothing can be done is that the type of an array includes its size. I would love to hear how someone was able to write an operating system in standard Pascal, if they did.
guy@rlgvax.UUCP (Guy Harris) (01/08/85)
> >Hey, c/mon fellas! Pascal was designed as an introductory language for > >a first programming course. Of course, it's restricted! ... A toy language > >(like Pascal) is not appropriate for building operating systems. > > Ah John, perhaps you should have a short talk with the folks over at Apollo. > They built an entire os, a transparent shared file system, network and > graphics system using Pascal. 1.e6 bucks says they didn't do it in standard J&W Pascal with no extensions. For one think, J&W Pascal has no way of declaring a procedure whose source is in another file than the source file that contains the use of the procedure - I don't think the folks at Apollo wanted to waste their time building an editor which can efficiently handle a source file consisting of the entire code of their operating system... Wirth didn't develop Modula-2 just for fun - he wanted to take the lessons learned from Pascal and build a language suitable for production use. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
henry@utzoo.UUCP (Henry Spencer) (01/08/85)
> > The problem with Pascal was that the original language was excessively > > minimal. We *have* avoided this trap with C, since it was in heavy use > > for production work long before K&R, much less the current ANSI effort. > > Hey, c/mon fellas! Pascal was designed as an introductory language for > a first programming course. Of course, it's restricted! A full system > language (like C) is not appropriate for Programming 101. A toy language > (like Pascal) is not appropriate for building operating systems. I'm not heaping scorn on Pascal; I was a founding member of the Pascal Users Group. (Literally: I was at the little meeting at ACM 75 that started the group.) But Pascal's problems are not restricted to cases where it is being misapplied. How can one teach defensive programming without an OTHERWISE in the CASE statement??? Oh well... -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
rudell@ucbcad.UUCP (01/09/85)
> Ah John, perhaps you should have a short talk with the folks over at Apollo. > They built an entire os, a transparent shared file system, network and > graphics system using Pascal. It has dynamic runtime binding (unlike unix) > and shared runtime libraries (unlike unix). > The system is not shabby - it's real fast AND supports C. > > Not bad for a "toy language". > > (personally, I would have done the work in C, but it shows that that vehicle > is not the only concideration, the destination is...) > > -- > > J Bradford Parker Wait one minute. You can hardly call what Apollo used standard Pascal. It is a language which will run on no other machine. They essentially added many C-like constructs (free pointers, a notion of modularity (they even call them static and extern!) to the syntax of Pascal. The argument was that Standard Pascal is a toy language. Apollo Pascal is a real language, but unfortunately, no one but Apollo uses it. Sure, a "standard" Pascal program will get close to running on the Apollo (assuming you never try to open a file given a specific filename, or binary search an enumerated-type :-)
keith@seismo.UUCP (Keith Bostic) (01/12/85)
>> reply to the recent spate of "Pascal >> is a wonderful system language" articles Come on -- let's not start a PASCAL vs. C debate, okay? Read Kernighan, Bell Labs Computing Science Technical Report #100. Pascal in its standard form is simply not useable for anything except cute little application programs. I'm not cutting it down -- I'd rather teach Pascal to freshman than anything else I can think of. But it doesn't cut it in the real world. If you want to extend it, fine. But, then, it's not really Pascal, now, is it? The same argument applies to all the extended Basics out there. You can extend a language to slice, dice and do julienne fries, but it's only good taste to refrain from arguing that the original version did/does all those things. Keith Bostic ARPA: keith@seismo UUCP: seismo!keith
ron@brl-tgr.ARPA (Ron Natalie <ron>) (01/15/85)
> You can extend a language to slice, dice and do julienne fries, > but it's only good taste to refrain from arguing that the original version > did/does all those things. > Multilevel standards are like onions. They're smelly and make you cry a lot. -Ron