Xref: utzoo comp.arch:20923 comp.lang.misc:6637
Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: standard extensions
Message-ID: <6049@mentor.cc.purdue.edu>
Date: 16 Feb 91 14:08:39 GMT
References: <1087@kaos.MATH.UCLA.EDU> <14814@lanl.gov> <1991Feb15.192653.9846@rice.edu>
Sender: news@mentor.cc.purdue.edu
Followup-To: comp.arch
Lines: 97

In article <1991Feb15.192653.9846@rice.edu>, preston@ariel.rice.edu (Preston Briggs) writes:
> >pmontgom@euphemia.math.ucla.edu (Peter Montgomery):
> >> The requested operation returns q and/or r, where
> >> 
> >> 		a*b + c = q*n + r   and   0 <= r < n
> 
> jlg@lanl.gov (Jim Giles) writes:
> >You will, unfortunately, recieve little sympathy for this kind of
> >request.  The UNIX community, in particular, will accuse you of
> >requesting a 'swiss army knife' compiler.
> 
> He has my sympathy; it's free.
> However, I won't spend much time inventing special syntax
> or optimizations for specific problems.  There are however,
> many people working on many ways of expressing and implementing
> extensible languages.  "They" don't belong to a special club;
> everyone is free to join.  It's very simple and fairly popular:
> 
>     while (dissatisfied) {
> 	Design a language (perhaps an extension of another language)
> 
> 	Implement your language (perhaps hacking an existing compiler
> 	or building an iterpreter).
> 
> 	Write many programs in your language to gain experience
> 	with its limitations.  Try and get others to use it.
>     }

This assumes that the one who needs the operations, or the
improved performance, has the resources and time to do this.
Montgomery and Silverman are number theorists, I am a professor
of Statistics and Mathematics.  We are expected to do other
things.

Mathematicians are used to the idea of an extensible language
for communicating to reasonably intelligent beings.  A computer
is not an electronic "brain"; it is an extremely fast sub-
imbecile.  Someone remarked elsewhere on the complexity of
the code in Fortran to handle x**y; there is necessarily 
separate code for each combination of types of x and y, and
even code taking into account particular values of x and y.
Producing translators of this magnitude is a major project,
and there are not adequate macro translators even available.

I believe that such a macro translator could be produced,
and with that it would be easy to use machine language,
rather than the overly restrictive assembler languages
designed essentially so as to be easy for the machine to
read.

What is needed in addition is a language which allows
the introduction of operator syntax according to the
user's desires.  The above production

> >> 		a*b + c = q*n + r   and   0 <= r < n

is understood by essentially any mathematician, and
it should not be necessary to do more than provide a
template to convert this into code.  Of course, that
does nothing to get the operation into hardware.  The
RS/6000 has a*b+c in floating point, using double
double arithmetic internally but not reusably.
One of the reasons behind putting this into hardware
is that it is relatively easy, and it would be even
easier for integer arithmetic.  From an architecture
standpoint, to a mathematician there is not that much
difference between integer and floating point, floating
point being the more complicated.

> Some people repeat the process many times (e.g., Wirth).
> Other people have problems they want solved and don't
> wish to get pulled into an infinite loop.  They can keep
> complaining; but I don't expect to see any results.
> Language designers aren't satisfied with existing languages
> (or they'd be out of the loop); they're busy - designing,
> implementing, testing.  They've got their own agenda.  You
> might be able to sneak your pet idea on someone's agenda,
> but it's probably expensive.
> 
> If you want it done right, ...

Wirth is being employed to design and develop languages and
related things.  In addition, he has available for this development
somewhere between a squad and a platoon of assistants.  This is
extermely important; it is difficult to catch one's own minor
errrors, even in something as flexible as English, designed to
be read by an intelligent being.  Communicating to a machine is
much harder.  There is also the need for people to do the routine
work.

For Montgomery or Silverman or me to produce the language would be
more than asking an individual automotive designer to do everything
from idea to prototype without any assistance whatever.  
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)