🚀 go-pugleaf

In article <596@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>[reguarding access to machine specifics from high level languages]

See Stanley Shebs's article <5084@utah-cs.UUCP>.  I will not address those
topics which he addresses.

>Are we to be limited to those features which are portable to all machines?
>If we do this, the only arithmetic operations we can allow are fairly short
>integer arithmetic; ...

You are still oriented on supporting the hardware instead of describing a
solution.  A real high level language is independent of the word size.  If a
machine does not have a long integer, the implementation of the language must
build it from short integers.

>... of the machines I have looked into in the past few years, no two have the
>same floating-point arithmetic.

Given that highly accurate floating point routines are heavily dependent on
specific floating point formats, this is a problem.  No high level language
will be portable from machine to machine when the formats are different.  The
IEEE floating point standard should help.

>The languages should not be designed around the quirks; they should be
>powerful enough to enable the programmer to make use of the quirks. ...  I am
>not advocating a language to optimize a specifice machine.  I believe that a
>language should be sufficiently powerful that the intelligent programmer can
>optimize on whatever machine is being used at the time.

Any language which allows the programmer to make use of the quirks must make
them visible.  This makes the language complex, difficult to understand,
difficult to reason about and makes the resulting programs non-portable.

>I can give competitive algorithms for generating normal random variables on
>the CYBER205 which I know, without programming them, will not be competitive
>on any of the other machines I have listed above.

If you are trying to get 100% performance, you will have to use assembler.
No language that has any meaning beyond a single machine can hope to meet your
needs.  It seems that your real complaint is that assembler languages are too
verbose, not that high level languages do not allow sufficient access to the
machine.  It should not be too hard to whip together an expression-based
"pretty" assembler.

>I question the need for a language which will keep the user ignorant of the
>powers of the computer.  I also question whether such a language, unless very
>carefully presented as incomplete, with sufficiently many indications of its
>deficiencies, will facilitate the eventual enlightenment of the learner; ...

Very few languages are incomplete in the sense of being able to compute an
arbitrary function.  However, assembly languages are examples of incomplete
languages.  All languages are incomplete with respect to their support of
the programmer for some application area.  It is true that there are no
languages tuned to the machine specific implementation of highly optimized
numerical libraries.  I suspect it would look very much like the "pretty"
assembler.

>Unfortunately, some machines such as the CRAY do not provide decent fixed
>point multiplication; on such machines it is necessary to work around it, and
>one may find it advisable to totally revise the algorithm.

You apparently program in a very narrow world where performance is everything.
The vast majority of programming is not done in such a world.

>The user should be able to introduce type definitions (structures in C), new
>operators (such as the very important &~, which may or may not compile
>correctly), and overload old operators.  This should be very flexible.

C++ allows programmers to introduce new types and overload existing operators.
It does not allow the definition of new operators, but does allow definition of
functions which achieve the same effect at the cost of a slightly more verbose
syntax.

>The VAX has twelve general-purpose registers available.  If I write a program
>which uses eleven registers, I object to the compiler, which does not need any
>registers for other purposes, only giving me six.

So complain to the compiler writer.  This is not the fault of the language or
of its designer.

>[Efficient code takes longer to produce than inefficient code] because of the
>badness of the languages.

Effient code takes longer because the algorithms are generally more complex,
not becuase the languages are bad.

>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
-- 
  Lawrence Crowl		716-275-9499	University of Rochester
		      crowl@cs.rochester.edu	Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl	Rochester, New York,  14627