🚀 go-pugleaf

In article <910@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

>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.

In other words:  when you look at a language, you look to see how low a
level it is and how easy and convenient it is for you to hand optimise
in it.  This doesn't sound like you want a *high* level language to me.

>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.

Don't you mean NON-portable software?  To me, semi-portable software
means that the machine-dependent parts are isolated and that's all that
has to be changed when porting to a different machine.  With your
ideas, the machine-dependent parts would be tightly integrated with the
rest of the software; this is what makes porting a nightmare.

>> 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.

What, from a functionality point of view, can't you program in PL/I
that you can program in all assembly languages (and, for a given
assembly language, would need no changes whatsoever when porting it to
another machine which uses the same CPU)?  In other words, what
machine-independent OS-independent code are you referring to that can
be done in assembly but not done in PL/I?

>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."

What would you have chosen for xor, considering a very limited
keyboard, and that most of the other symbols were taken?  C was created
in the early 70s, when a PDP-11 was considered state-of-the-art.
Remember, C was not intended to be a verbose language; keystrokes were
to be kept at a minimum.  Given these conditions, what would you have
chosen?

>This is similar to the use of \ for an escape character.

I pose the same question as above.  And remember, the escape character
should be one character, be printable, and the ESC key did not exist on
most keyboards at the time.

>Language designers should have more respect for even moderately established 
>notation in mathematics and computational theory.

Well, this is funny considering mathematicians don't show respect for
moderately established notations.  sin^(-1)(x) should not mean
arcsin(x), abuse of the ' symbol, d/dx not really division, etc.  And
they aren't limited by what appears on a keyboard, either.  Language
designers do the best they can; the only other way to do things is to
invent new symbols for everything (')+(' for non-associative
[floating point] addition, etc.), and that is not practical in
reality.

>> 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.

Who invented the f(x,y) syntax anyway?  It sure wasn't the computer
gurus.  Prefix notation is extendable (arbitrary number of arguments),
infix is not (well, not easily).  And quite frequently I find myself
having to add another parameter to a function when I try to generalize
it.  This would be very difficult to do with infix notation.

>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.

Well, unless you have a nice graphics terminal, you aren't inventing a
symbol; you are merely using an ordered collection of other symbols to
represent your own.

>I see the problem of assembler language that it is functional notation
>and not overloaded operator.

I never found this to be a problem when I programmed in assembler.  I
liked having a 1:1 correspondence between assembly language and machine
language, and overloaded operators would most definitely go against
that.  And if you, a mathematician, have so much trouble with
functional notation write yourself a preprocessor.

>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?

Many already do.  It occurs in a very old language; a language about as
old as FORTRAN.  It's call LISP.

Or, did you mean to ask that addint(x,y) be used for adding integers,
addreal(x,y) for adding reals, etc.?  If you did, then I answer No, I
don't want to have to do this.  That is one of the reasons I'm using an
HLL in the first place!  And how do you propose to define the
overloaded operators?  If you do it the C++ way, you haven't escaped
your original problem, only moved it.

>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.

Then WRITE a language, and show us that this is indeed better.

>One point concerning the above.  Standard mathematical operations can produce
>more than one result.

And many functions can produce more than two results.  If you are going
to generalize, then do it right!

>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.

A LOT of overhead if you only need one.

And why should a programmer programming in a HLL care whether these can
be performed simultaneously.  He specifies what he needs in the HLL,
and the compiler is supposed to generate the best possible machine code
for doing that.  If the compiler isn't doing that you should be
complaining about the implementation, not the language.  Neither of
these two examples show any inherent problems with most HLLs (C, PL/I,
etc.); the problems are with a given implementation.

 _ __		NEVIN J. LIBER  ..!att!ihlpb!nevin1  (312) 979-4751  IH 4F-410
' )  )			 Anyone can survive being frozen in liquid nitrogen;
 /  / _ , __o  ____	  it's surviving the *thawing* that counts :-).
/  (_</_\/ <__/ / <_	These are NOT AT&T's opinions; let them make their own.

P.S.:
In article <6966@well.UUCP> Jef Poskanzer <jef@rtsg.ee.lbl.gov> writes:

@I just did some find/sed/grep hacking to find out just how prevalent
@cross-posting is.

@Here are the people who cross-posted to five groups:
@, Herman Rubin,

Congratulations!