🚀 go-pugleaf

In article <24294@megaron.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
>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.

Actually, it doesn't fit into #3 because a run-time check is
available. But it's not what you say, it's what you mean.

>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.

I think this would probably just have the effect of lulling
programmers into thinking they can alias some of the time, so they'll
screw up and alias at the wrong time, and the error will not be caught
because no compiler provides run-time checks for aliasing. I also
can't think of a single reason why you'd ever want to do aliasing of
the type which is illegal.

I don't like kitchen sink languages. If your FORTRAN optimizer deals
with non-aliased arguments, it needs more smarts to deal with aliased
arguments. Why make the compiler and language bigger just to deal with
someone's brain-damaged coding style?

>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.

I have the silly idea that programmers appreciate concise languages.
How much money would you have me pay to my compiler writers just to
add that "feature"? But what do I know, I just *use* the language
we're talking about.

--
"In fact you should not be involved in IRC." -- Phil Howard