Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc Subject: Re: Third public review of X3J11 C Summary: So lets fix these, and others Message-ID: <910@l.cc.purdue.edu> Date: 2 Sep 88 12:21:22 GMT References: <8365@smoke.ARPA> <225800053@uxe.cso.uiuc.edu> <8374@smoke.ARPA> <340@quintus.UUCP> Organization: Purdue University Statistics Department Lines: 109 In article <340@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes: > In article <908@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > >In article <8660@ihlpb.ATT.COM>, nevin1@ihlpb.ATT.COM (Liber) writes: > >> But the part that isn't irrelevant is *why* did PL/1 turn out, in your > >> words, to be a badly designed language? We don't want to go around > >> repeating the mistakes of the past if we don't have to. > > > >A language should be easy to read and as easy to write as possible. The > >kludges made in PL/1 to allow the use of the properties of the machine were > >to use the common assembler notation, which while it is precise, is difficult > >to read and write. > > > I used to use PL/I (yes, that's an "I" not a "1"), and I'm afraid I don't > quite know what Herman Rubin is getting at here. It is not surprising that we do not always notice the same things. The first thing I notice about a computer is what its instructions can do, and how convenient it is to juggle the quantities (to me a quantity is anything, not just a number) around. When I see a language, the corresponding question is whether the designers have provided a way for me to use the hardware instruc- tions, and how easy and convenient it is for me to do that. Consequently, the first thing to strike me about PL/I is that the insertion of the hardware instructions the gurus did not consider in their infinite wisdom worthy of including in the language is forced to be in the same clumsy form which discourages the use of assembler language. That the language designers do not consider this problem important is, I believe, the major problem in producing efficient semi-portable software. > PL/I syntax, for those > who are fortunate enough not to know it, is full of things like > PUT FILE (OUTFILE) EDIT (THIS,THAT,THE_OTHER) (A(10)) PAGE; > Roughly, >
{ [()]}... ; > For another example, > CALL PROCEDURE(ARG1, ..., ARGN); This type of syntax, through calls, can be easily used in just about any HLL (C has gotten rid of the word CALL), except that the use of the would have to be handled in some other way. I do not find that notation much different from the usual. > For an example of arithmetic operations, to add two MxN arrays of > floating point numbers: > DECLARE (A,B) BINARY FLOAT DIMENSION (1:M, 1:N); If C had multidimensional arrays, and did not require indices to start at 0, such as PASCAL and recent versions of FORTRAN permit, it would be nothing new to C. The wording would be slightly different. > A = A+B; Overloaded operators to the front! > I have no desire to praise PL/I, but I honestly don't see any resemblance > to any of the assembly languages I've ever used. I repeat, what about the multitudinous operations which the gurus have not included. > As for infix notation, I wish someone would come up with a standard > notation for sequence concatenation: I've seen "+" (which mathematical > convention reserves for commutative operations), "&" (which looks like > "and"), "*" (which makes the most sense, but is rare), and the theory > papers tend to use a sign which is a bit like ^ and a bit like the > intersection sign, and needless to say isn't in the ISO 8859/1 character set. The only assembly language I have used in which I used this used ^. I do not know of any use for ^ other than concatenation and power (or superscript) until the C gurus came up with the idea of saying, "Nobody uses this, so we will use it for exclusive or." This is similar to the use of \ for an escape character. Language designers should have more respect for even moderately established notation in mathematics and computational theory. > In the absence of an agreed notation for such a fundamental operation, > the use of functional notation has a lot to commend it. This is a major bone of contention and interpretation. I consider that a binary operator function normally uses an infix symbol. It may be necessary to invent a corresponding symbol, which need not be a single character, for the purposes of a program if one is not available. I see the problem of assembler language that it is functional notation and not overloaded operator. What do you think the reaction of HLL users would be if you required them to write addint(x,y) for x+y if one wanted to add the integers x and y? As an example of how a language can and should be extended if the need arises, I have a function (which I will not describe here, nor will I give the algorithm), which requires the following: long long integers (at least two more bits than the exponent in a double) Boolean operations and additions on such packing and unpacking of doubles into (exponent, mantissa), the mantissa being a long long integer in addition to the usual operations. I maintain that any acceptable language should allow such additions, including the temporary addition of infix functions, if necessary. One point concerning the above. Standard mathematical operations can produce more than one result. A simple example is division, with quotient and remainder. Another example is that one frequently wants both the sine and cosine; it is only about 30% more expensive to produce both of them simul- taneously than to produce one. I can give other examples. Thus one should be able to put a string before the = sign in a replacement statement. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)