gast@ucla-cs.UUCP (01/28/85)
There has been some discussion about passing constants by reference and then changing them. Some attribute this to an optimizing compiler, others to other reasons. It is quite easy to test for this problem at compile time--before the optimization phase even begins. It seems clear that in any reasonable implementation of a language like FORTRAN or Pascal, such behavior should be illegal. The Berkeley pascal compiler will not, for example. IBM in a non-standard implementation feature goes one step further. (I will not comment on the advisability of using non-standard features) You can pass parameters by value, reference, or CONST. CONST is like call by reference except you cannot assign to the constant. Further, it is impossible to change that variable in a another procedure call. E.g. main calls p passing a by const. p cannot call q passing a and have q change a.
jbn@wdl1.UUCP (01/31/85)
Ada has IN, OUT, and IN-OUT arguments. This is clearly the right way to go. By-reference or by-value then becomes an implementation detail.
ndiamond@watdaisy.UUCP (Norman Diamond) (02/04/85)
> Ada has IN, OUT, and IN-OUT arguments. This is clearly the > right way to go. By-reference or by-value then becomes an implementation > detail. Except that we still have to "outlaw" aliasing and most of the other classical problems... -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
rcd@opus.UUCP (Dick Dunn) (02/12/85)
> Ada has IN, OUT, and IN-OUT arguments. This is clearly the > right way to go. By-reference or by-value then becomes an implementation > detail. It's only an implementation detail if the abstraction of your particular problem is more concerned with the gozinta/gozouta-ness of the arguments. Reference and value parameters provide an equally valid abstraction. And, of course, there are real-world problems with mud and bits stuck to them, where the question of which "implementation detail" was chosen is the major issue. In other words, "...clearly the right way to go..." is nothing but a subjective opinion. Ada was not the first language to try the IN/OUT/IN- OUT device, and other languages since Ada haven't flocked to it. I recall joking in a physics class about the way we made simplifying assumptions--something like "frictionless elephants whose mass can be neglected." There seems to be a programming-language equivalent in "instantly copyable objects whose storage can be neglected." -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Cerebus for dictator!