🚀 go-pugleaf

In article <1992Nov17.155855.4413@let.rug.nl> bert@let.rug.nl (Bert Bos) writes:
>In article <1992Nov16.080647.26783@informatik.uni-ulm.de>, borchert@titania.mathematik.uni-ulm.de (Andreas Borchert) writes:
>> Agreed, programmers shouldn't be enforced to use VAR-parameters
>> for reasons of efficiency only. But, even with the semantics of
>> Oberon or Modula-2, it's not to difficult for the compiler to
>> detect that your 1000 x 1000 array isn't modified and, thus,
>> doesn't need to be copied.
>> ...
>But what about a PROCEDURE p(a: Type; VAR b: Type) that is called as p(x, x). Both parameters will refer to x, but if b is modified, a should remain unchanged.

A good point, showing that my suggestion of constant vs. variable
is worse that value vs. variable as far as regards aliassing problems.
Thus, there would indeed be some merit in having three parameter modes
(as somebody suggested in this thread):
value, constant, and variable (and possibly yet something like 'out'
in Ada, i.e. a result parameter).

Fortran, I think, has a rule stating that if a formal parameter is
modified within a subprogram, the corresponding actual parameter must
not be the same as any other actual parameter in the call.
Does Modula-2 or Oberon have a similar rule?  (Value parameters need
not be considered, but constant parameters would if passed by reference.)
Of course, those breaches of the rule that cannot be detected at compile
time could be too expensive to catch at run time.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------