Oleg N. Cher писал(а):
Dear Josef, dear Norayr,
After years of working in Oberon language and a good understanding of its features and problems, let me propose you a new feature that you can add to Ofront and voc: IN parameters of procedures as in Component Pascal.
An Oberon developer, choosing a method of passing a string inside a procedure, must choose between using direct parameter (with duplicating the entire array or record, which can be not so small), or using VAR-parameter which does not guarantee the passed structure or an array of unwanted changes, and also does not allow an immediate string value, but only a variable or a pointer.
But yeah, you know it well. It was one of the annoying problems of Oberon and Oberon-2. And BlackBox guys, using Oberon-2 for industrial applications, also encountered this. That this problem was not resolved in time, generated a lot of incompatible decisions:
The Oakwood Guidelines, 5.13 Read only VAR parameters
There have been many requests to make ARRAY and RECORD parameters read-only to achieve the efficiency of passing by reference without the associated possibility for corruption of the calling parameter.
An attempt to make an assignment to any component of such a read only parameter is a compile-time error. Such parameters could be marked with the standard read only "-" symbol. For example:Код: "OBERON"
PROCEDURE Print (theText-: ARRAY OF CHAR) ;
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.Amiga-Oberon v3.11, F. Siebert / A+L AG:
Код: "OBERON"
PROCEDURE Print (theText: ARRAY OF CHAR); (* $CopyArrays- *)
Ofront:Код: "OBERON"
PROCEDURE Print (theText: ARRAY[1] OF CHAR) ; (* Good, but the feature is SYSTEM and incompatible with other Oberon compilers *)
Eventually Wirth also added this capability to Revised Oberon:
Oberon-07:
Код: "OBERON"
PROCEDURE Print (CONST theText: ARRAY OF CHAR) ;
In many other implementations of Oberon-2 this problem was not solved.
After comparing all the suggestions, I chose the option that is implemented in Component Pascal (BlackBox, GPCP) in order to also implement the symmetric parameters OUT in future.
I am really sure that the strength of Oberon is a clear regulation of interprocedural and intermodular interactions, and we have no right to lose this valuable feature. But certainly we should not miss the opportunity to raise the visibility of module interfaces. What we can tell by looking at parameter VAR? What is it? Input value? Output value? Is this changeable value? Does a developer really wants to pass input value and want to have output value, or uses VAR here only for optimization?
All these considerations lead to the conclusion that the IN and OUT-parameters is not such a bad idea. I can assure you that compiler's complication with this feature enough slightly - one additional procedure, and only a couple dozen lines of code. But I'm sure that if we rewrite Ofront using IN-parameters, its efficiency will be significantly improved.
Here are commits that implements IN-parameters. Thank you.
https://github.com/Oleg-N-Cher/Ofront/commit/c50a1ee95854ea7f7187a879b888156b79ee70d0https://github.com/Oleg-N-Cher/Ofront/commit/de1061d27a1e25cee0bda89cf93a63d3f8ce94d5https://github.com/Oleg-N-Cher/Ofront/commit/5aa4232bc9d94b0db63c6998429812cc8f732ef2Test of IN-parameters:
https://github.com/Oleg-N-Cher/BB-XDev/commit/7fb3d4b789cdb32c8216e2823a2c1b4dce1b9c49I tested that code a few days, and indeed most of the code is taken from BlackBox, but if you notice a problem, let me know.
--
Oleg N. Cher
VEDAsoft Oberon Club
https://zx.oberon.org