🚀 go-pugleaf

One of the main ideas behind high-level languages is to provide a virtual
machine that is mostly independent of the low-level hardware.  So, trying
to make a language that allows full access to the low-level destroys this
abstraction which language designers have fought so hard to achieve.  If
Herman wants machine features, then why does he insist on using a high-level
language which, by its very nature, is designed to rid him of having to
be concerned about such things?  Destroying this illusion makes such code
much more difficult to understand as the machine environment must be included
as well as the semantics of the language.  Why do you think that assembler
is so much less portable than an HLL?  That is the major issue here; the
level of abstraction.

On a slightly less ethereal level, if Herman wants a 32 x 32 -> 64 multiply
instruction, then I suggest that the real problem is not that the language
doesn't let him specify this particular instruction, but that the language
doesn't let him specify his data to a sufficiently high degree.  PL/I allows
a declaration including the number of bits of storage.  Occam allows BYTE,
INT, INT16, INT32 and INT64 (so the 32/32 -> 64 will work) for integer types.
What should be done to circumvent this is to force all integer variables to
be declared using ranges, so that the abstraction is retained by implying
that you don't particularly care how something is done, as long as it is
done.  Herman could then declare i,j : -2**31..2**31-1 and k : -2**63..2**63-1
and expect a decent compiler to pick the right machine instructions to do

	k := i * j

as a 32*32 -> 64.

If you want to use other, more perverse, instructions, then why not use small
functions to do it.  On VMS, there are several function such as LIB$INSQHI
to access some of the special instructions *that are peculiar to the VAX*?
(There is even a LIB$EMUL for doing 32*32 -> 64 multiplication :-) ).
Put such things in a library - don't junk up a language to do it.  No other
machine that I can think of has interlocked queue instructions, so what use
is carrying around VAX stuff in a language that is to be used on 68k/*86
and any other type of stuff.  I don't want to pay (in terms of compiler cost
and complexity, bugs and size) for your little, one-off, instruction hacks.
That's one of the good things about K&R C.  Everything's in libraries, so
I don't have to use your stuff if I don't want it.  Don't destroy my
abstraction for your "do it all in one instruction" bodge.  I want a lean,
mean, hungry and beautiful language and not a kludge-up like C or PL/I or
ADA or FORTRAN or .....

	Hubert Matthews