🚀 go-pugleaf

In article <8E+4_83@ggpc2.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes:
> In article <2419@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
> > You are denying the artisan the tools.
> 
> Oh, garbage. If you're writing non-portable code anyway use assembly.
> Or... have you considered Forth?

I have never objected to having semi-portable code.  Most of the code
called portable is really in this class, and making Fortran fully portable
would make it so slow as to be almost useless.  Which machine's floating
point representation are you going to use?  The several supercomputers I
know, as well as the VAXen, are different from IEEE.  If fact, their
hardware as actually implemented on several models predates IEEE floating-
point standards.

The situation is not quite as bad for integer arithmetic, if the sizes of
the objects are the same, but it can be even then.  If one machine has
8 bit bytes and another 9, there are problems, but good.  When characters
are read, if 8-bit characters are allowed, is there sign extension or not?

Forth is also clumsy and inefficient.  An intelligently written assembler,
which allowed overloaded operators and weak typing, would be useful, as
would a versatile macro processor.  For those who claim they have one,
the following

	c{'z} ={tc} {-}{|}{ta}a{'x} OP{mod} {|}{tb}b{'y} {/\{~}w}

is the way I would write the general vector instruction on the CYBER 205.
with braces enclosing optional fields.

Portable constructs are one thing, but portable code is another.  Packing
and unpacking floating-point numbers are portable constructs, but I know
of no HLL which has them.  These should be operators, not function calls.
The idea of open subroutines, a cross between macros and inlining, existed
at the time of Fortran I.  Fortran VI on the CDC3600 allowed 3 additional
types (to make a total of 8), and allowed the user to define the Fortran
operations on these types, but only by subroutine calls.  Why can we not
have additional operator SYMBOLS added to a HLL?  C and C++ allow additional
types, only they do not call them types.  I was informed by soeone at ATT
that the non-allowance of additional operator symbols in C++ was an
unfortunate oversight.

I have not run into anything which can not be written in a semi-portable
manner.  But in choosing which of the extremely large number of algortithms
I can understand, I do take into account the machine.  Remember that all of
the present machines, and even pocket calculators if they were equipped with
a large enough memory, are capable of doing anything that any other machine
can do, although it may very well be very inefficient.  Any language can
simulate any other, although not always well.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)