🚀 go-pugleaf

In article  <1990Aug16.204409.4744@murdoch.acc.Virginia.EDU> gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) writes:
>
>Try this for an example: FORTRAN doesn't allow aliased arguments in
>subroutine calls. This allows FORTRAN compilers to make all sorts of
>nice optimizations.

This example fits so obviously into scenario (3) that I feel I must
not have expressed myself at all clearly.  Maybe if I explain this
example in detail it will clear things up:

Let's design FORTRAN++, a proper extension of FORTRAN.  Legal FORTRAN
programs are compiled exactly the same way in FORTRAN++ as in FORTRAN,
including the optimizations that come from assuming no aliasing.  But
in FORTRAN++, there is a subroutine declaration that tells the
compiler a given subroutine _can_ have aliased arguments.  When it
sees this declaration, a FORTRAN++ compiler does not do the
optimizations, and does not check for aliasing in procedure calls (if
it does otherwise).

FORTRAN++ programs are just as efficient as FORTRAN programs as long
as the programmer doesn't take advantage of the new declaration.  If
the programmer _does_ declare a subroutine as having aliased
arguments, then presumably he feels the extra expressiveness is worth
the performance loss.  It would be a good idea to check the
consistency of these declarations at link time, although if you don't,
FORTRAN++ is no less secure than FORTRAN.

I have this silly idea that the programmer (at coding time) is better
at making decisions on how to write a particular program than is the
language designer at language-design time.  Face it, the programmer
knows a lot more about the problem area and resource constraints than
the language designer does (who had no idea that anyone would be using
his language to solve that problem in that environment).
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman