Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc Subject: Re: Language Tenets Summary: Clarification and rebuttal Message-ID: <1430@l.cc.purdue.edu> Date: 21 Jul 89 13:46:41 GMT References: <57125@linus.UUCP> <1989Jun24.230056.27774@utzoo.uucp> <15941@vail.ICO.ISC.COM> Organization: Purdue University Statistics Department Lines: 134 In article <15941@vail.ICO.ISC.COM>, rcd@ico.ISC.COM (Dick Dunn) writes: > anw@maths.nott.ac.uk (Dr A. N. Walker) writes: > . . . > > (a) Is it a language deficiency if "q r <- t/b" cannot be sensibly > > written? Answer: yes... > > This brash conclusion is fair warning that unwarranted generalizations are > to be found. Considering that many people have already claimed this to be a deficiency, the statement that this is a brash conclusion is even more brash. Since (except possibly for recent developments) every grade school graduate knew that a division had a quotient and remainder, why is it brash to require that this can be sensibly written in a computer language. > A "deficiency" in a language must be judged in context of the intended use > of the language. Therefore a general statement that this is a deficiency > is wrong...in a language where the need is rare, no deficiency exists. That someone who cannot see the need for something does not make it reasonable to call the need rare. Many others have argued that it is not rare. And we have the railroad paradox; if the train will not stop, nobody wanting to use it will be at the station. > > (b) Should all possible machine-code short-cuts be expressible within > > the language? Answer: yes... > > If you have asm's, you can write lots of machine-code shortcuts assuming > the hooks are provided to give you access to variables, parameters, etc. > But this is not "within the language" in any useful sense! The "asm" > facility is explicitly an escape from the language. The asm facility is a massively clumsy escape from the language. Also, most compilers make the interface fantastically difficult. It is generally necessary to do massive editing of the assembler output. Besides, the assembler notation is almost deliberately designed to make it difficult for people to use. And if I am going to use an instruction an appreciable number of times, why should I not be able to write it in a sensible manner? > > ...I know of several quite old languages in which the embedded > > machine code could include expressions, provided that certain restrictions > > were observed. Where it matters, there are ways of making this portable. > > The notation can be made quite portable, but the instructions themselves > cannot. What's going on here--was this an assertion that we can have > portable machine language, or only that we can posit a relatively portable > notation for assembly language? We can have semi-portable machine language, and extremely flexible notation not just for assembler instructions, but also for HLL operations not now included. A few examples of HLL operations not now expressible conveniently. The "&~" operation, hardware on many (most?) machines. Some compilers on some machines will handle the symbol pair. The power operator. Not to be confused with the power function. The power operator is highly overloaded. Unpacking floating point, and the resulting packing. This frequently requires an integer type longer than long. And do it all without loading and storing everything which should stay in registers. > > (c) Should languages permit "functions with several results"? Answer: > > I don't know what the question means, but the answer is yes... > > That does it! This is complete nonsense! Possibly he should have said that there is more than one meaning to the question, but the answer is yes. A replacement procedure takes the quantities on the right side, performs the indicated manipulations, and replaces the variables on the left side by the appropriate values. There is no specification of the order of the replacement, that the quantities are in any way to have any more cohesion than just a list, or that at any time there is to be a single machine entity (other than scattered registers and memory locations) containing the results. So what is so brash about asking for that? > > ...it's harder to see how the function can be defined sensibly > > unless the objects are grouped in some way; but it is clearly a language > > deficiency if structures and arrays (as well as pointers thereto) cannot be > > returned from functions. Many popular languages are defective in this way; > > some are not. Well, I do not have this problem. A list of results is not that hard to understand. > Again, per above, it is a deficiency if the facility is needed for the > intended problem domain of the language. In many cases being able to > return a pointer is sufficient, and being able to return an array is at > odds with other design goals of the language. > > I wish all the would-be language designers would show some more care about > their suggestions. It's bad enough that they shoot at a very tiny area of > the language without a thought for how the pieces will fit together...and > here, without even a thought for how to solve the tiny target problem. I wish the designers of the languages would give up the arrogance that they know everything that the user will want to use. It is usually very difficult to add things to a language after the language has been produced, just as it can be very clumsy to do something in software which could have been cheaply included in hardware. I know of no language produced with the idea of even reasonably efficient code which will allow me to add new operator symbols-- I see now more reason why I should have to write pow(x,y) for x to the y-th power than you should have to write diff(x,y) for x-y. Even Fortran found it necessary to invent an infix notation for that. And do not tell me to write that part of my code in Fortran and another part in C. I may want to use both constructs in the same expression, and I expect that not to be unusual. One can avoid using features of a language which one does not wish to use, but the opposite is not the case. Not all primitive operations are expressed in the languages. And because of this, some of these operations are disappearing from the hardware. A lot more flexibility is available for little cost. I will not be so arrogant as to attempt to tell you everything which should be in a language. I do not even know what I might want to use tomorrow. Languages should be designed by people with this in mind. > Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 > ...Simpler is better. Sometimes. And what is simpler to you may not be to me. The order of pedagogical presentation of mathematics is far from unique, and I assure you that there is no unanimity on which way is best. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)