Xref: utzoo comp.arch:20876 comp.lang.misc:6626
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!rice!hsdndev!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Computers for users not programmers
Message-ID: <14814@lanl.gov>
Date: 15 Feb 91 15:49:54 GMT
References: <1087@kaos.MATH.UCLA.EDU>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 28

From article <1087@kaos.MATH.UCLA.EDU>, by 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
> 
> This operation is well-defined mathematically 
> [...]

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.  This would be a valid
point if the functionality you requested could be provided
efficiently by composing other features of the language.  What is
really needed is a two-fold approach: 1) the simpler features of
this kind need to be intrinsics of the language (or, at least one
language); 2) there needs to be a way for the user to define
operations which are 'inlined' _before_ optimization - and it should
be possible for these user defined 'intrinsics' to be written in
assembly.  This second requirement opens the possibility of
"supplimentary standards" which define language extensions as
packages of 'inlined' procedures.  Ordinary packages or modules
that languages already have are inadequate to this task due to
the fact that they can't be forced to 'inline' the code, and
they can't be written in assembly to take advantage of machine
specific instructions in ways the compiler writer didn't consider.

J. Giles