🚀 go-pugleaf

In article <1984@trantor.harris-atd.com>, chuck@melmac.harris-atd.com (Chuck Musciano) writes:
> Oh well, into the breach...
> 
> In article <1262@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
> >No apologies are due to the compiler writers.  Rather, criticism is due to
> >them for the arrogance they took in leaving out the possibility for the
> >programmmer to do something intelligent.  The HLLs are woefully inadequate,
> >and I would not be surprised that the ability to do intelligent coding using
> >the machine capabilities may be destroyed by learning such restrictive coding
> >procedures first.
> 
>      Some misdirected flames here.  If you want to blame anyone, blame the
> language designer, not the compiler writer.  Us poor compiler writers just
> sit around, horrified, as the hardware guys take more and more of the hard
> part and give it to us.  :-)

Not all blames go to the language designer.  The implementation of asm in C
can be done to give much more benefit to the programmer.  The implementation
knows where the variable xyz is and can substitute it in the assembler
instruction.  This has nothing to do with the language.

And this atrocious use of underscores!  Why should C prefix an underscore to
all its names for systems purposes?  I know the reason, but I cannot respect
the intelligence of those who did not take the other action.  If we have
programs created by several languages, we should have no more than a calling
sequence problem, not a name problem.  If I call a buffer refill program with
the calling sequence I advocate, passing the pointer descriptor, it should
make no difference whether the subroutine is written in Fortran, C, Pascal,
APL, or anything else, and it should make no difference whether it is called
from any of those languages.  If they all prepended an underscore, and each
could use the others' names, it would not be too bad.  But some Fortrans leave
the name alone, some prepend and postpend, Pascal does not allow underscores
in the middle of a name, etc.

>      If you dislike the current crop of HLLs so much, you are free to design
> your own.  As one who has designed and implemented several languages on a 
> variety of systems, I know how easy it is to take potshots at the language
> implementors.  Go through the loop yourself, and then complain.  Designing
> anything which will please some segment of the world is very difficult.
> Designing a language which is elegant, orthogonal, easy to learn and use,
> easy to implement on a variety of machines and that will appeal to a large
> number of users is almost impossible.

I am asking for one thing you have left out; it should be able to write
efficient code.  I will throw out elegant and orthogonal completely.  If
the machine is not orthogonally designed, why should the language be.  And
most machines are not.

The first thing needed is a macro assembler in which the "macro name" can be
a pattern.  For example, I would like    x = y - z    to be the =- macro.
Allow the user to use these ad lib.  This way the language can be extended.
The #defines, and even the user-overloaded operators in C++ do not achieve
this.  If a machine instruction is complicated, it may be necessary to have
a complicated design, as well as type overrides, etc.  An example from the
CYBER 205 is the following large class of vector instruction, where A or B
can be either vector or scalar.  There are many options in this, and I point
this out.

		C'W =t -|A'X opmod | B'Y /\ ~ W
		 11  2 34 55   666 7  88 99 a 9

notice that I have 10 options for each opcode (someone might say that option
6 is part of the opcode, but there are natural defaults).  Since this is a
single machine instruction on this machine, I MUST be able to use it, and I
do not wish to have to use the clumsy notation provided by the "CALL8"
procedures.  I do not claim that this is optimal notation, and I would 
expect you to write it somewhat differently.  For example, you could always
leave out the /\; I put it in merely for clarity.

The best semi-portable procedures for generating such random variables as
normal are easily described.  Coding them on a CYBER 205 efficiently is
trivial.  Coding a slightly different version of them on an IBM 3090 is 
not difficult.  Coding them (any version) on a CRAY X-MP is an interesting
challenge.  Coding them on a CRAY 1 is a major headache, and not vectorizable
for much of the procedure.  These vector machines are that different.  So
should the code be easy to implement on a large variety of machines?  But
the programmer who does not understand the machine cannot code well on that
machine.

Some C-like language with macro augmentation is probably the answer.  But
types and operation symbols should be introduced by the user at will.  And
all manners of arrays should be included, and whatever else the user can
come up with.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)