🚀 go-pugleaf

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,
> 	<main keyword> {<sub keyword> [(<argument list>)]}... ;
> 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 <sub keyword>
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)