🚀 go-pugleaf

In article <1992Nov19.104407.338@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>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).

The Turing language offers two paramter modes, variable and
"constant".  Their solution to the above problem is that actual
variable parameters must be unique, although the above sort of problem
was not the explicit reason for doing so.  Their justification was
that the logic of the procedure assumes that different variable
parameters are different variables, and so the compiler shoulf enforce
it.