Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.misc
Subject: Re: He's not the only one at it again!
Message-ID: <3481@goanna.cs.rmit.oz.au>
Date: 29 Jul 90 14:39:40 GMT
References: <388@e2big.mko.dec.com> <25630@cs.yale.edu> <2404@l.cc.purdue.edu> <1990Jul26.020229.2205@murdoch.acc.Virginia.EDU>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 51

In article <1990Jul26.020229.2205@murdoch.acc.Virginia.EDU>, gsh7w@astsun.astro.Virginia.EDU (Greg S. Hennessy) writes:
: In article <2404@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
: #I claim I have made a strong case against ALGOL being even a good programming
: #language for mathematics. 
 
: Because certain computers had hardware instructions that ALGOL could
: not use, then ALGOL is not a good programming language for
: mathematics. I don't understand the logic, because for ANY language,
: there will be machines that have instructions that cannot be used.

If you want a *portable* programming language, that's so.
But is a class of programming languages ``MOHOLs'' which provide access
to all the instructions of the machines they are intended for.
On the B6700: ESPOL contains Algol as a sublanguage, but there is no
B6700 instruction which it cannot generate.
On the IBM/360:  PL/360 can generate any instruction; if there is an
instruction the compiler normally doesn't generate you can declare it
and then use it as if it were a subroutine or function.
On the DECsystem-10:  BLISS-10 and BLISS-36 can generate any instruction;
if there is an instruction the compiler normally doesn't generate (or,
for that matter, which the machine hasn't got, such as a UUO) you can
declare it and use it as if it were a subroutine or function.
(It helps that the DEC-10 instruction set is very regular.)

As it happens, Algol 60 in practice had a way of getting any instruction
whatsoever into your programs, namely procedures with "machine code" bodies.
I've seen it used.

Herman Rubin was talking in this instance about instructions which are useful
for multiprecision integer arithmetic.  Actually, that's the wrong way of
thinking about it.  The _right_ way to think about it is to realise that
integers being confined to nasty little boxes is an artefact of computers,
_not_ a feature of our programs.  If I declare
	var x: 12223495872309457 .. 2345230549872039458720983475;
then any compiler worth its salt ought to be able to figure out how many
of its nasty little boxes to use, and how to exploit whatever instructions
the architect may have provided for "multiprecision arithmetic".  The
language to slam is not Algol, which merely imitated Fortran in this
respect, but Pascal, which (a) had the example of COBOL before it,
and (b) had the notational resources (subranges) to let programmers give
the compiler enough information to do the job without imposing its nasty
little boxes on *us*, but (c) went ahead and rammed nasty little boxes
down our throats anyway.  (I prefer languages where integers are as big
as they need to be without me having to bother; Yay Lisp! Yay Scheme!, 
but Pascal's subrange notation *could* have been exploited to ensure that
integer arithmetic on ranged variables was completely portable, without
requiring dynamic allocation of numbers.)

-- 
Science is all about asking the right questions.  | ok@goanna.cs.rmit.oz.au
I'm afraid you just asked one of the wrong ones.  | (quote from Playfair)