Re: By value-result vs by reference

Theo.Norvell@comlab.oxford.ac.uk (Theo Norvell)
Tue, 26 Apr 1994 13:57:06 GMT

          From comp.compilers

Related articles
[3 earlier articles]
Re: By value-result vs by reference hbaker@netcom.com (1994-04-21)
Re: By value-result vs by reference Dik.Winter@cwi.nl (1994-04-21)
Re: By value-result vs by reference nebbe@lglsun.epfl.ch (1994-04-22)
Re: By value-result vs by reference andrewd@apanix.apana.org.au (1994-04-24)
Re: By value-result vs by reference hbaker@netcom.com (1994-04-23)
Re: By value-result vs by reference nebbe@lglsun.epfl.ch (1994-04-26)
Re: By value-result vs by reference Theo.Norvell@comlab.oxford.ac.uk (1994-04-26)
Re: By value-result vs by reference hbaker@netcom.com (1994-04-28)
Re: By value-result vs by reference anton@mips.complang.tuwien.ac.at (1994-04-29)
Re: By value-result vs by reference nebbe@lglsun.epfl.ch (1994-04-29)
Re: By value-result vs by reference hbaker@netcom.com (1994-05-01)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Theo.Norvell@comlab.oxford.ac.uk (Theo Norvell)
Keywords: design
Organization: Oxford University Computing Laboratory, UK
References: 94-04-145 94-04-163
Date: Tue, 26 Apr 1994 13:57:06 GMT

andrewd@apanix.apana.org.au (Andrew Dunstan) writes:


>Barring the presence of an exception, the only way that you can "tell the
>difference" [between by-reference and value-in-value-out]
>in Ada is to write a routine that has a side effect directly
>modifying its parameters, i.e. by aliasing. If you write code like that
>you deserve what you get.


In Turing (and I am quite sure Euclid). Potential aliasing of "var"
parameters is prohibited, detectable, and detected by conforming
compilers. In fact, for large (i.e. nonscalar) value parameters, the same
prohibition is in effect. Thus large value parameters may be passed by
reference too.


In many ways this is a good thing. On the other hand, since aliasing and
potential aliasing are not the same thing, one is often thankful if ones
compiler does not treat this error as a fatal error.


> The language designers should not be required to
> cater for idiots writing bad code.


Good language designers recognize that even the best programmers are
occasionally idiotic. They also consider that maintenance is usually the
most costly part of the software life-cycle.


Theo Norvell
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.