Re: By value-result vs by reference

nebbe@lglsun.epfl.ch (Robb Nebbe) writes:
>I have seen many people point out many problem in different languages that
>all fall under the category of "the evil programmer". If a programmer
>wants to break some code it can certainly find a way in pretty much any
>language.


Yes, but the whole point of type systems is to try to either 1) find the
break at compile time before it can do any damage; or 2) find it at run
time in a way that maps into the programmer language's model of the
computation. Ada actually went to a lot of trouble to achieve both 1 & 2,
so its lapse in this area of reference v. value-result is quite
uncharacteristic.


>It is sort of like the fact that you can cast away const'ness in C++; so
>what, at least it's explicit.


Is this the 'everybody does it, so it must be ok' theory of programming
semantics? :-)


>A ADT for these types would typically have one parameter that can be
>modified with the rest being constant. The problem here is that some code
>might work if you used value/result and it would be incorrect if you used
>by reference (if the parameter to be modified is aliased to one that is
>"constant"). Maybe it would have been better to always require
>value/result :-)
>
>I really don't think that value/result is the villan some people make
>it out to be.


Why is this problem such a hard concept to understand? As I said before,
call by value result in a language in which people are intuitively
thinking about 'object identity' is formally identical to utilizing a
hardware cache which doesn't have 'cache consistency'. The compiler which
uses value/result and then classifies aliasing as 'erroneous' is trying to
'blame the programmer' for the shortcomings of the value/result approach.


Most people that see a flaw in some mechanism acknowledge the flaw, and
then try to live with it by being especially careful. I acknowledge that
value/result can in some circumstances be advantageous, and I would like
the language semantics to make clear the circumstances under which this
mechanism can be used safely and cleanly.


Your approach seems to be to simply declare the problem away, and say that
value/result -- whatever its semantics -- are just fine.


If you really believe this, and a significant number agree with you, then
perhaps most of the work on hardware cache coherency has been a waste of
time and money. My guess is that most HW architects would be thrilled if
the cache coherency problem went away, because their read and write
pipelines would be immensely simplified, and clock rates would jump
dramatically. From now on, we just tell all programmers that if they
depend upon cache coherency, their program is erroneous.
--

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