daveb@laidbak.UUCP (Dave Burton) (03/10/88)
I'm redirecting this to comp.lang.misc - it's lost all its flavor of C. (Herman, I won't be reading comp.lang.misc, if you want, Email me - Dave) In article <703@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: |Frankly, I believe that if someone developed a decent high-level, overloaded |operator, reasonable syntax assembler it would have a good chance of |supplanting C. Add the other useful features of C and you have a good |language. My definition of assembler may be antiquated, but it says that there is a one-to-one (or one to _very_ few) source statements to target statements. I do not think such a beast as your hypothetical super-assembler is likely. I do think C could be improved on in several areas, but which direction? Should C's successor be system implementation oriented, or general purpose oriented; i.e: more explicit control of the underlying machine, or more generalized, higher level constructions? #asm is not of the latter. |Suppose that you have a situation in a program where the implementation of |your compiler has done something bad, like use 10 instructions and 6 memory |references where 2 instructions and no memory references can do the job. |The overhead of a subroutine call is likely to be more than what can be |saved; a goto construction may not work if part of the problem is that the |compiler will mess up register use (very common). The number of situations where the matter of a few microseconds is a make or break proposition is extremely limited. Where they do occur, they are non-portable. These situations are very likely best handled in assembly for that routine, anyway. |Also some of the very simple hardware operations which are useful for some |problems have not been anticipated by the language developlers. This is so |often the case for simple operations frequently found in hardware. More |machines have a hardware operation &~, which most mathematicians normally |use \ for, than have the operation &. I am more likely to want to use &~. If I understand you properly, you want to switch between a HLL and assembly, with regularity, to use machine specific instructions. I think this is in contrast to the basic principles of high-level languages. HLLs are designed to allow a higher level of abstraction than assembly, and somewhat more portability. |If a programmer says that something is inline, and this should be a feature |of any language, the compiler should at most point out why this is not good, |but the judgment must be that of the programmer. Something troubles me about this statement, but I don't know what. I'm inclined to agree. |> [ on language gurus claiming omniscience, deleted ] |The language gurus may not claim this, but I am not so sure. The |designers of 4.xBSD clearly state in their assembler documentation |that the assembler is _not_ for programmers, but for compiler designers |and system maintainers. I believe this is not so much omniscience as practicality. I *like* programming in assembly. I like the control, the flexibility. But I have never written a major application under Unix in pure assembly. Why should I? I can be much more productive in C. Because it's so inconvenient to do assembly hacking, almost nobody does it. With so many using C, lisp, f77, ratfor, efl, what-have-you, why expend a great deal of effort on an assembler used 99% percent of the time by automated software? |But in too many cases, the existing HLLs may produce good code if small |modifications are made. In many cases, these modifications are machine |independent--I can give you cases of this. It may even be as simple as |saying | This is what is needed; implement this block efficiently, while | maintaining its compatibility with the rest of the program. | |That is another reason for asm. Isn't this actually arguing against asm? |> You presume that this same individual also knows how the HLL |> implements itself on that machine. This is not the case. Very few people |> that know both the HLL and the machine instruction set will know what kind |> of code the compiler will produce. |Why not? OK, I know this is not quite the same, but consider interpretive languages. Who knows what shadows lurk ... :-) These include not only BASIC (ack!), lisp, prolog, sno[bol], but "4GL"s like SQL, Informix, Accel and the too many others. Even with compilers, many people do not _take the time_ to learn the transformations performed upon their HLL by the compiler. I never bothered to study the output of FORTRAN or Ada, but I know the assembly language for the machines I write them on. The point is, I and most others don't get paid to cogitate the most efficient possible expression for situation X. (Not that I would mind! :-) It just isn't necessary to know. -- --------------------"Well, it looked good when I wrote it"--------------------- Verbal: Dave Burton Net: ...!ihnp4!laidbak!daveb V-MAIL: (312) 505-9100 x325 USSnail: 1901 N. Naper Blvd. #include <disclaimer.h> Naperville, IL 60540
pase@ogcvax.UUCP (Douglas M. Pase) (03/16/88)
In article <703@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: |Frankly, I believe that if someone developed a decent high-level, overloaded |operator, reasonable syntax assembler it would have a good chance of |supplanting C. Add the other useful features of C and you have a good |language. A suggestion for all those Monday morning quarterbacks out there who love to rip on other languages: If you have such great ideas, design and implement your own. You'll discover that making a language consistent throughout can be a major task. You'll discover that writing the compiler is not always the most difficult part of the process -- but writing the compiler will show you many of the holes. You'll also discover that your idea of a "perfect language" may not be so widely held. When you're done, report the results and distribute the compiler, then let the general public be the judge. If your ideas are as good as you really think, you'll be acclaimed a hero and go down in history as one of the all time greats -- up there with Nikky W. and the infamous K&R. Jim (uh, John -- no, Jim...) Backus will probably even personally shake your hand. If you think you really can do better than ``C'' or some other successful language, *** DO IT ***. (Though I generally detest Fortran and Pascal, I doubt I could have done much better at the time they were created -- for the niches they fill.) I would be suprised if your design were much different from existing languages (except perhaps in minor details -- 0/1 trip loops, 0/1 based arrays, for-do-while vs DO-REPEAT-etc., `;' as terminator/separator, and so forth.) -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu (CSNet)
cik@l.cc.purdue.edu (Herman Rubin) (03/18/88)
In article <1592@ogcvax.UUCP>, pase@ogcvax.UUCP (Douglas M. Pase) writes: In article <703@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: |Frankly, I believe that if someone developed a decent high-level, overloaded |operator, reasonable syntax assembler it would have a good chance of |supplanting C. Add the other useful features of C and you have a good |language. > .... You'll also discover that your idea of a "perfect language" > may not be so widely held. I do not believe that it is possible to design a perfect language. I may have gone too far in claiming even that one can get a good language. However, the first requirement for an _adequate_ programming language is that if I start with a reasonable mathematical construct, and the hardware can implement that construct in a simple manner, that the language must allow the resulting program steps to be at least that good Another requirement of mine is that it is not necessary to type a large number of characters to do something simple. Compare a typical assembler with CAL. Mathematicians have been dealing with overloaded operators for centuries; they have been adding operators for centuries. If a mathematician needs a new operator, he introduces it in his paper and defines its properties. This does not mean that his symbolism gets adopted. Similarly, it a new operator is needed in a program, the programmer should be able to define and introduce it. There are two different aims of a programming language. One is the description of the procedure. For this, the current languages are totally inadequate. They are much too restrictive, as well as lacking in scope. Consider the following problem: We wish to add the elements of the array _a to those of array _b, forming array _c. Most programming languages provide an imple- mentation of this; in fact C provides at least three. If this is what we want done, we should not tell the compiler which of the three to use; that should be machine dependent. Thus the language does not provide for the proper expression of the concept. On the other hand, few languages provide for reasonable integer arithmetic, or multiple precision arithmetic, integer or floating, at all. They only provide for certain fixed precisions. The other aim is to provide source code which a reasonable compiler can transform into reasonably efficient code for production purposes. Here it is necessary to have the language flexible enough to accommodate machine dependencies. It is necessary to have access to the machine instructions. It is necessary to restrict portability. Semi-portability may still be desirable. The "super-assembler" which I suggested in my previous posting is for this purpose. Most programming languages are bad attempts in this direction. It is easy to give examples where the choice of which procedure to use should be machine dependent, even though the language is powerful enough to encode each procedure for each machine. > If you think you really can do better than ``C'' or some other successful > language, *** DO IT ***. If you provide me with the necessary programmers, I will. > (Though I generally detest Fortran and Pascal, I > doubt I could have done much better at the time they were created -- for the > niches they fill.) FORTRAN had obvious inadequacies before it was created. ALGOL claimed to be a good language for all of numerical mathematics for all time--it was clearly inadequate on the machines existing at that time for the problems being done at that time. The following is a quote from D. H Lehmer, one of the pioneers in the use of the computer in number theory. I do not remember the exact words, but the meaning is clear. "None of the existing languages is adequate for number theory. Furthermore, I would not be able to design one." Clearly, Lehmer did not mean that he could not program number theory computa- tions. It is also clear that the standard mathematical expressions are an adequate means of communicating the algorithms so that a programmmer with the knowledge required to _read_ the mathematical notation could come up with some sort of correct implementation. We still do not know enough to come up with an efficient implementation by a compiler using source in any of the existing languages. > I would be suprised if your design were much different > from existing languages (except perhaps in minor details -- 0/1 trip loops, > 0/1 based arrays, for-do-while vs DO-REPEAT-etc., `;' as terminator/separator, > and so forth.) > -- > Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu (CSNet) I agree the above are minor details. The ability to define types as needed and operators as needed, to ignore types when necessary, to use such machine hardware as the language designer does not know about, to use condition codes when convenient if available, etc., are extremely important. We have the problem and the machine; we must educate people to use the tools the machine provides to solve the problem. We also need to be able to write the necessary constructs with a reasonable number of keystrokes, and the notation should be reasonably easy to read. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet
jcb@its63b.ed.ac.uk (J Bradfield) (03/18/88)
There *is* a better language than C---it's called BCPL!
pase@ogcvax.UUCP (Douglas M. Pase) (03/24/88)
In article <l.712> cik@l.cc.purdue.edu (Herman Rubin) writes: > However, the >first requirement for an _adequate_ programming language is that if I start >with a reasonable mathematical construct, [...] Imperative languages are built around the concept of a state machine -- statements in the language are transformations from one state to the next. There's nothing inherently un-mathematical about that. In fact, Floyd, Hoare, and others have developed a rather interesting mathematical structure around such machines. If you would argue that it isn't "reasonable", well, many persons smarter than I am have varying opinions on what is "reasonable", and they don't necessarily agree with you. (I use the term "state machine" in its more general sense -- I am not refering to the FSM of language theory.) >There are two different aims of a programming language. One is the description >of the procedure. For this, the current languages are totally inadequate. >They are much too restrictive, as well as lacking in scope. Did you ever wonder why those "restrictions" are there? Do you think it's because those who designed the languages ``just weren't smart enough to do the job right?'' It's very very easy to design a language which is internally inconsistent. Many of the inconsistencies do not become apparent until one actually tries to *implement* the language. Some are not even known until much later than that. Another thought, people use programming languages for many different purposes. Does this mean that we should look for that one "reasonable" mathematical structure which subsumes all possible uses for computers? Ridiculous! Some languages attempt to do just about that (Ada and PL/I immediately come to mind), but it is questionable that they succeed at it. >It is necessary to restrict portability. Semi-portability >may still be desirable. You may consider this a desireable feature, but I, for one, do not. >In article <1592@ogcvax.UUCP>, pase@ogcvax.UUCP (Douglas M. Pase) writes: >> If you think you really can do better than ``C'' or some other successful >> language, *** DO IT ***. >If you provide me with the necessary programmers, I will. Here I am. If you come up with a language description sufficiently precise that it can be implemented, I'll be happy to produce a working compiler. It doesn't require an army of programmers to *design* a language. Besides, why are you trying to foist this part of the task on others -- you're supposed to be the one with the ideas. Even writing a compiler for your proposed language shouldn't be that much of a problem for you -- unless you have no idea how a compiler works. If this is the case I would be a bit more skeptical about your ability to design a language. (Yes I realize that some compilers require many man-years of effort. One needn't implement a full-blown all-the-bells-and-whistles compiler the first time around.) >The ability to define types as needed >and operators as needed, to ignore types when necessary, to use such machine >hardware as the language designer does not know about, to use condition codes >when convenient if available, etc., are extremely important. These are noble goals, and they have been incorporated into various languages with varying success. (Roll-your-own-operator is done in Prolog, define- your-own-type is a feature of CLU and (I think) Ada, ``C'' allows you to ignore types when you really want to, plus it allows access to the "bare metal", etc.) >We also need to be able to write the necessary constructs with a reasonable >number of keystrokes, and the notation should be reasonably easy to read. Some argue convincingly that verbosity is an advantage. Others argue against it. Some think ``C'' is easy to read but Pascal isn't; others believe the reverse. Everyone seems to have an opinion on this stuff. I have not recognized much in your postings that was not opinion. If you have something more substantial than gut feelings, please share it with us. As best I can tell you have not yet proposed much beyond a number of vague design goals with a small set of "features". You haven't even described your language's intended use. This is one reason why I suggest you flesh out your ideas a bit more. Your ideas may very well be dead on the mark -- gut feelings are sometimes right. If you did work out more of the details we would be better able to consider your ideas a bit more objectively. Through this whole article I have spoken strongly, but without intent to offend. If for any reason something I have said gives offense, please accept my personal apology. -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu (CSNet)
blarson@skat.usc.edu (Bob Larson) (03/25/88)
In article <1600@ogcvax.UUCP> pase@ogcvax.UUCP (Douglas M. Pase) writes: >``C'' allows you to >ignore types when you really want to, The only way it allows you do do this is via unions, equivelent to pascal's varient records. Casts are (by definition) conversions, while some seem silly and produce no code on many machines, they still never allow you to "ignore types". Pointers DO NOT violate this, while it is possible to cast any pointer to a void or char pointer and back, it is not required that the char pointer be meaningful. (Ever heard of "split I & D"? How about extending this so char and int storage are seperate?) > plus it allows access to the "bare >metal", etc.) Are we talking about the same language? -- Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%fns1@ecla.usc.edu oberon!fns1!info-prime-request
henry@utzoo.uucp (Henry Spencer) (03/27/88)
> >``C'' allows you to > >ignore types when you really want to, Well, not quite: what it allows you to do is to cheat the type system. You still have to be aware of it, so in a strict sense you aren't "ignoring" types, but you can get around the restrictions they impose. > > plus it allows access to the "bare > >metal", etc.) > > Are we talking about the same language? Probably. One of C's strengths -- and a major reason for its popularity -- is that it *does* let you get at much of the underlying machine if you really want to *and* understand your implementation in detail. It's not enough to understand C and the machine, you have to understand the mapping between them that the compiler provides. But once you do, you can use C to do most of the things an assembler can do. C insists on managing the stack and some of the registers itself, places constraints on what you you can do to the PC, and won't generate funny instructions for you, but these limitations often aren't a problem. Otherwise it opens the machine up pretty thoroughly, *if* you know what you're doing. -- "Noalias must go. This is | Henry Spencer @ U of Toronto Zoology non-negotiable." --DMR | {allegra,ihnp4,decvax,utai}!utzoo!henry
blarson@skat.usc.edu (Bob Larson) (03/29/88)
In article <1988Mar27.002601.17038@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >> > plus it allows access to the "bare >> >metal", etc.) >> Are we talking about the same language? >Probably. One of C's strengths -- and a major reason for its popularity -- >is that it *does* let you get at much of the underlying machine if you >really want to *and* understand your implementation in detail. AND your machine happens to match C fairly well AND your implimentation does a straitforward mapping. > It's not >enough to understand C and the machine, you have to understand the mapping >between them that the compiler provides. But once you do, you can use C >to do most of the things an assembler can do. This can be said of most high level languages. > C insists on managing the stack and some of the registers itself, ?some? Are you implying that there are C implementations that use the register keyword for anything other than a promise not to take the address? :-) > places constraints on what you >you can do to the PC, and won't generate funny instructions for you, Does this include the funny instructions added for use by the C compiler? :-) (Prime expended their 32i mode instruction set into 32ix mode mainly for use by the C compiler.) > but >these limitations often aren't a problem. Otherwise it opens the machine >up pretty thoroughly, *if* you know what you're doing. C opens up an idea of what a machine could look like. Not all machines look like that. Some machines have basic concepts difficult or impossible to express in C. (Such as a dec 10/20 "byte pointer" [variable size bytes]) C is a high level language that closely models some common architectures. It is a mistake to think it can be used for "access to the 'bare metal'" without specifying what 'bare metal' you are thinking of. (Not all the world is a vax or pdp11 or 68k or spark.) -- Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%fns1@ecla.usc.edu oberon!fns1!info-prime-request
nevin1@ihlpf.ATT.COM (00704a-Liber) (03/29/88)
Doug, sorry to put my comments as a followup to your article, but Herman Rubin's article has expired here. In article <1600@ogcvax.UUCP> pase@ogcvax.UUCP (Douglas M. Pase) writes: >In article <l.712> cik@l.cc.purdue.edu (Herman Rubin) writes: >>There are two different aims of a programming language. One is the description >>of the procedure. For this, the current languages are totally inadequate. So is mathematics. That is why most problems are described in the natural languages (I think that is the term) such as English, German, etc. Herman, if you think that mathematics is such a great descriptive language, please send me a description of limit theory using only mathematical symbols :-) :-). No English (or other natural languages) allowed!! :-) >>It is necessary to restrict portability. Semi-portability >>may still be desirable. Well, if you want me to help you prototype your language (see below), you had better provide me with the same hardware that everyone else is using. My vote is for a Cray Y-MP :-) :-)! >>In article <1592@ogcvax.UUCP>, pase@ogcvax.UUCP (Douglas M. Pase) writes: >>> If you think you really can do better than ``C'' or some other successful >>> language, *** DO IT ***. > >>If you provide me with the necessary programmers, I will. > >Here I am. If you come up with a language description sufficiently precise >that it can be implemented, I'll be happy to produce a working compiler. Me, too. However, you (Herman Rubin) must convince me that you language is 'better' than what we currently have. It shouldn't be all that hard to code the prototype compiler for your language. However, one of my definitions of a 'good' general-purpose computer language is the ability to write a compiler for itself in it. Since you are the only one who knows your language, you are the only one who can write the final compiler. When you provide us with FORMAL specifications of your language (such as the C reference manual in the K&R C book), then you can worry about getting programmers to help you code it. When you have something that resembles a language definition and specification, instead of a mish-mash of contradictory ideas, come back to the net and impress us. Until then, stop all this unconstructive criticism on current languages and start working on your language design!! -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
pase@ogcvax.UUCP (Douglas M. Pase) (03/31/88)
I (Douglas M. Pase) write: - plus it allows access to the "bare metal", etc. Henry Spencer writes: -One of C's strengths -- and a major reason for its popularity -- -is that it *does* let you get at much of the underlying machine if you -really want to *and* understand your implementation in detail. In article <oberon.7924> blarson@skat.usc.edu (Bob Larson) writes: -AND your machine happens to match C fairly well AND your implimentation -does a straitforward mapping. -C is a high level language that closely models some common -architectures. It is a mistake to think it can be used for "access to -the 'bare metal'" without specifying what 'bare metal' you are -thinking of. (Not all the world is a vax or pdp11 or 68k or spark.) K&R page 180 reads: "... Some implementations also reserve the words *fortran* and *asm*. ..." For those implementations which support ``asm'', you may insert assembler code directly into the program. That sounds like "bare metal" to me. Try putting a few asm("assembler code goes here"); statements in your code and dumping the assembler listing. If you want to argue that it's not "real ``C''" go ahead, but that's not my problem. -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu (CSNet)