lindato@tektronix.UUCP (Linda Todd) (12/02/83)
In the 1981 US Dept of Commerce NTIS report #4634, A. Evans of BBN has some great quotes: I get the impression that C's designers were charged $1000 for every reserved word in the language and $2000 for every concept, that C programmers are charged $5 for every character in the program, and that minimizing this cost was a major design goal. ... With short int, int, and long int, the C programmer can specify enough information so that the compiler will probably get it right. The governing word here is "probably", an idea which seems to pervade much of C's design. To my way of thinking, "probably" isn't good enough, and I feel quite unconfortable about this aspect of C.
shebs@utah-cs.UUCP (Stanley Shebs) (12/06/83)
A. Evans of BBN has probably never had to write real programs, or else has brainwashed himself into supporting Ada. If you don't think minimizing the number of reserved words is a good idea, try Lisp. At 1000 or more reserved words (the oblist), it's not always easy to avoid stepping on things, and the results of a collision are usually quite mysterious. As for the compiler "probably" doing the right thing, I don't think there's *any* existing portable language in which the compiler can be guaranteed to give consistent results - 36 bits is different from 32, no matter how you try to disguise it... stan the lep hacker utah-cs!shebs
ggs@ulysses.UUCP (12/07/83)
With regard to the following: >If you don't think minimizing the number of reserved words is a good idea, >try Lisp. At 1000 or more reserved words (the oblist), it's not always >easy to avoid stepping on things, and the results of a collision are usually >quite mysterious. Foul! There are very few reserved words in Lisp. The conflicts with the oblist are no worse that function name conflicts in the C library. The only cases that I can think of where strange things happen are when you re-bind some of the atoms that have special significance to the interpretor (input or output radix, for example). You can redefine a procedure and cause a system function to break, but you can also do the same thing to a function in the C library. The conflicts are an attribute of the large size of the support library, not of the language. >As for the compiler "probably" doing the right thing, I don't think there's >*any* existing portable language in which the compiler can be guaranteed to >give consistent results - 36 bits is different from 32, no matter how you try >to disguise it... Lisp is just such a language. It allows you to deal with abstract objects that have little relation to the underlying architecture. I wrote a fairly large language interpretor in Lisp in 1969. It ran under Lisp 1.6 on a PDP-10. I was able to port it to Franz Lisp on a VAX in 1983 with about one day's effort. The changes were to eliminate some non-standard function references that I shouldn't have used in the first place. The resulting code would run on the original PDP-10 system with only a few lines of changes. -- Griff Smith AT&T Bell Laboratories, Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs
blenko@rochester.UUCP (Tom Blenko) (12/07/83)
If you don't think minimizing the number of reserved words is a good idea, try Lisp. At 1000 or more reserved words (the oblist), it's not always easy to avoid stepping on things, and the results of a collision are usually quite mysterious. Foul! There are very few reserved words in Lisp. The conflicts with the oblist are no worse that function name conflicts in the C library. The only cases that I can think of where strange things happen are when you re-bind some of the atoms that have special significance to the interpretor (input or output radix, for example). You can redefine a procedure and cause a system function to break, but you can also do the same thing to a function in the C library. The conflicts are an attribute of the large size of the support library, not of the language. Oh, come on! If you want to argue about reserved words in Lisp, the only argument is whether there are any reserved words at all. Maybe t and nil. The oblist contains names from the global name space. If you reference a variable without declaring it, it is treated as global. If you don't want to keep track of which global names are used by the interpreter, declare local variables (that's good programming practice anyway). Let's not make this any more complicated than it really is. As for the compiler "probably" doing the right thing, I don't think there's *any* existing portable language in which the compiler can be guaranteed to give consistent results - 36 bits is different from 32, no matter how you try to disguise it... Lisp is just such a language. It allows you to deal with abstract objects that have little relation to the underlying architecture. I wrote a fairly large language interpretor in Lisp in 1969. It ran under Lisp 1.6 on a PDP-10. I was able to port it to Franz Lisp on a VAX in 1983 with about one day's effort. The changes were to eliminate some non-standard function references that I shouldn't have used in the first place. The resulting code would run on the original PDP-10 system with only a few lines of changes. Fine. How about your floating point arithmetic? Lisp is more portable than many other languages. No, it's not perfectly portable. So what's new?
alan@apollo.UUCP (Alan Lehotsky) (12/07/83)
Regarding the comment from "Stan the Lep Hacker" >>> A. Evans of BBN has probably never had to write real programs, or else >>> has brainwashed himself into supporting Ada. since I had Prof. Evans for a programming linguistics course when I was at MIT, I tend to believe that he knows what he's talking about. [ That's in addition to my own personal opinion that C is brain-damaged...] From bitter experience, I know that language design is MUCH harder than most people suspect. Just look at the syntactic disaster in C for the old form of assignment-operators such as: a =+ b /* same as a += b, for non-trivia collectors... */ and consider the amusement possible when you feed a compiler something like... a =/* comment */ b; Now, is this the same as: a = b; or should it be parsed as: a =/ (*comment) * (/b); and complain about the fact that the second "/" cannot be used as a unary operator? This may not be completely fair, cause they eventually did fix this problem. But there are other, equally obscure problems with C, especially since the language definition isn't very definite.
shebs@utah-cs.UUCP (Stanley Shebs) (12/07/83)
I have to apologize for not knowing who Art Evans is. It seems the quotes about C were taken a little out of context... For everyday programming, the Lisp oblist is *all* reserved words - most Lisps have some very obscure function names; mung those and you're without an interpreter. In Franz, try the global var "base" - it's lots of fun! BTW, I consider C library function names to be reserved words. Perhaps they don't fit somebody's formal definition of "reserved word", but messin' with 'em is dangerous, and that's what counts. Portability is easy when you restrict yourself to subsets, but full language implementations and operating systems are a little more difficult. PSL is implemented in itself, and it's very difficult to make things like garbage collectors and compilers that are both portable and written in Lisp. I also notice a distinct dearth of portable Un*x implementations in anything other than C. Say, since the tide seems to have turned towards abusing C and friends, what is the official explanation of the reason that things like C and Basic are so much more heavily used than all the "correct" languages like Pascal, CLU, Turing, Praxis, and the many others? Are most programmers just dumb? Inertia (but Pascal is pretty old)? Or is "Real Programmers Don't Use Pascal" less tongue-in-cheek than it appears at first guffaw? stan (the l.h.!) shebs utah-cs!shebs
neal@denelcor.UUCP (Neal Weidenhofer) (12/09/83)
************************************************************************** >For everyday programming, the Lisp oblist is *all* reserved words - >most Lisps have some very obscure function names; mung those and you're >without an interpreter. In Franz, try the global var "base" - it's >lots of fun! BTW, I consider C library function names to be reserved >words. Perhaps they don't fit somebody's formal definition of "reserved >word", but messin' with 'em is dangerous, and that's what counts. I've been concerned for some time now about where the "language" leaves off and the "library" takes over. Especially since Ada came on the scene; in Ada (as I understand it), the programmer is encouraged to think of not only public but private library routines as extensions to the language (at least in some sense--they're also very sensitive about any "extensions" to Ada.) As a language developer, this strikes me as an extremely powerful and useful paradigm but the formal descriptions haven't kept up. I would like to see what other ideas there might be out there about this. Regards, Neal Weidenhofer Denelcor, Inc. <hao|csu-cs|brl-bmd>!denelcor!neal