Oleg-N-Cher / POW

The Programmers Open Workbench
http://www.fim.uni-linz.ac.at/pow/pow.htm
3 stars 0 forks source link

Remove the VAR for a parameter- #3

Closed Oleg-N-Cher closed 10 months ago

Oleg-N-Cher commented 10 months ago

PROCEDURE WriteStr (VAR text- :ARRAY OF CHAR);

Here we would like to remove the word "VAR" for a parameter- to make this conform to The Oakwood Guidelines and the Oberon-2 compilers that adhere to them (such as XDS, Ofront+ etc).

The word "VAR" is confusing here, because we can usually pass a string literal to such a procedure, and VAR is like saying it should only be a variable. And we would not want to deviate from The Oakwood Guidelines so as not to generate too many variants of syntax that can be unified.

Oleg-N-Cher commented 10 months ago

Well, about Issue 3 there is a nice summary at the end of the “Read only VAR Parameters” section: "Discussions with ETH suggest this is really a compiler code optimisation issue and on this basis it is recommended that this extension is not implemented. “

The Oakwood Guidelines recommend that compiler developers avoid par- by letting the compiler itself internally decide whether a parameter is immutable or modifiable.

In general, of course, an Oberon compiler will hypothetically figure it out by itself - corresponds to the spirit of Oberon.

We have studied this question in our small Russian-speaking Oberon community. Almost every more or less serious implementation of Oberon-2 includes some kind of its own solution for r/o parameter like a-: ARRAY ... or (in Amiga Oberon):

PROCEDURE Request(Text: ARRAY OF CHAR); (* $CopyArrays- *) (On the plus side, it is compatible with the regular Oberon-2, which does not have this feature implemented)

So the problem of determining whether a parameter is r/o at the compiler level has not been solved by just about anyone. And here's why. And it's not even about single-passing. Why hasn't anyone done it? Maybe there are some pitfalls?

VAR write: ARRAY 100 OF CHAR;

PROCEDURE DoVar (IN read: ARRAY OF CHAR); (* Component Pascal *)
BEGIN
  (* read = "123" *)
  write := "Abc";
  (* read = "Abc" *)
...
END DoVar;

BEGIN
  write := "123"; DoVar(write);

Thus we get r/o parameter. write := "Abc" changes it. And let's imagine that this write is a global variable of another module, and it is changed externally by another procedure of another module, third, fifth, tenth. Thus, to make sure that a parameter is invariable, it is not enough to check the invariability inside one procedure, you need to check the whole chain. All this is quite non-trivial, so "-" is the lesser evil. Especially from the point of view of simplicity.

VAR wr*: ARRAY 100 OF CHAR;

BEGIN
  wr := "123";
  Print(wr); (* "123" *)
  AnotherModule.Proc; (* <-- call a procedure that externally changes the wr of our module *)
  Print(wr); (* not "123" *)

So, you should attach to each procedure a hidden list of all structural variables it changes. And it should be available in the interface. In this case, this external procedure can be indirectly called via a pointer, addressed from somewhere else, in short, it's hard to trace.

Imagine, we call a procedure by a procedure pointer, and it can internally call procedures of other modules that can change the hell out of things.

I think if one variable has to be passed as r/o and then the same variable has to be passed to be changed, it's hard to trace by simple means. And nowhere in existing compilers we know of does it occur. So let's conceptualize structural r/o parameters not as unchangeable, but as a fixed unchangeable reference to an external variable that can be changed, but just in a different way.

All this is of course not a classical copying of a parameter, as is done in Oberon-2. And the IN way is not a substitute for it, only a compromise. So I will insist that parameter- is a working solution that avoids unnecessary complexity. And the developers of the Oakwood Guidelines clearly did not envision all the problems and complexities of tracking the immutability of a structural variable-parameter. Otherwise, they would not have so easily advised compiler authors to do so.