Read-only parameters 
Author Message
 Read-only parameters

As much as I like the Oberon language definition in its pristine simplicity,
there is one item that obstinately remains on my wish list, and that I submit
you with the hope to not get flamed by ETZH.

Clearly array value parameters are required for reasons of language
orthogonality, but, as a practical software developer, I don't see uses galore
for this feature. Most of the time, when you transmit, lets say, an error
message parameter, the only thing you ever want to do with it, is to print it
out. Now, Oberon, as it is, obliges you to transmit the message as a value
parameter, and makes a local copy of it. So I dream about the following idiom:

       PROCEDURE foo (CONST errmsg: ARRAY OF CHAR) ......

The effect would be same as VAR errmsg, but the body would not be allowed to
make it an assignment target. Now you could call this procedure with a string
constant or literal.

Is this proposal worth to be considered ?

Dirk Muysers



Fri, 16 Feb 1996 16:57:31 GMT  
 Read-only parameters

Clearly array value parameters are required for reasons of language
orthogonality, but, as a practical software developer, I don't see uses galore
for this feature. Most of the time, when you transmit, lets say, an error
message parameter, the only thing you ever want to do with it, is to print it
out. Now, Oberon, as it is, obliges you to transmit the message as a value
parameter, and makes a local copy of it. So I dream about the following idiom:

       PROCEDURE foo (CONST errmsg: ARRAY OF CHAR) ......

I asked for this once and someone from the ETH pointed out the
aliasing problem that can occur.

MODULE M;
VAR msg : ARRAY OF CHAR;

PROCEDURE foo( CONST s : ARRAY OF CHAR );
BEGIN
END foo;

END M.

The problem is the msg can be passed as a parameter and
can be modified while foo is executing. This means that
the string is not the const that one was hoping for.

What is needed is for a const copy to be made. Then
a reference to this copy can be passed safely. The
next problem is where to the temporary copy to be made.

MODULE M;

VAR msg : ARRAY 32 OF CHAR;

PROCEDURE NoCopy( CONST s : ARRAY OF CHAR );
BEGIN
END NoCopy;

PROCEDURE Const( CONST s : ARRAY OF CHAR );
BEGIN   NoCopy( s ); (* no copy required *)
END Const;                              

PROCEDURE ValParam( s : ARRAY OF CHAR );
BEGIN (* s can modified here *)  
    Const( s ); (* copy required *)
END ValParam;                          

PROCEDURE VarParam( VAR s : ARRAY OF CHAR );
BEGIN  Const( s ); (* copy required *)
END VarParam;                            

PROCEDURE Pointer;
VAR s :  POINTER TO ARRAY OF CHAR;
BEGIN      
        NEW( s, 10 );
        Const( s^ ); (* copy required *)
END Pointer;

PROCEDURE ReadOnly( READONLY s : ARRAY OF CHAR );
BEGIN
        (* s is readonly value parameter *)          
        Const( s ); (* does not require copy *)
END ReadOnly;                          

END M.

Whitney



Sat, 17 Feb 1996 00:05:40 GMT  
 Read-only parameters

Quote:

>> Clearly array value parameters are required for reasons of language
>> orthogonality, but, as a practical software developer, I don't see uses galore
>> for this feature. Most of the time, when you transmit, lets say, an error
>> message parameter, the only thing you ever want to do with it, is to print it
>> out. Now, Oberon, as it is, obliges you to transmit the message as a value
>> parameter, and makes a local copy of it. So I dream about the following idiom:

>>        PROCEDURE foo (CONST errmsg: ARRAY OF CHAR) ......

>I asked for this once and someone from the ETH pointed out the
>aliasing problem that can occur.

Sorry, it can't. A read-only parameter could only be forwarded to a procedure that has
also a 'CONST something: ARRAY OF CHAR' signature. After all, the feature works quite
well in  -horresco referens- C++...

Dirk Muysers



Sat, 17 Feb 1996 15:56:07 GMT  
 Read-only parameters

|>
|> Clearly array value parameters are required for reasons of language
|> orthogonality, but, as a practical software developer, I don't see uses galore
|> for this feature. Most of the time, when you transmit, lets say, an error
|> message parameter, the only thing you ever want to do with it, is to print it
|> out. Now, Oberon, as it is, obliges you to transmit the message as a value
|> parameter, and makes a local copy of it. So I dream about the following idiom:
|>

[ Stuff deleted ]

I'm sorry, but I don't agree with you one bit.  Don't add CONST and
READONLY to Oberon-2 in respect of parameters.  They are not needed.

You're talking of dumb compilers which always copy the array on procedure
entry, regardless of the use which is made of it.  A good compiler can
determine when a copy needs to be made: if the parameter is not threatened
in any way, then no copy needs to be made.  Threatening can be from
aliasing, or from direct or indirect assignment.  If the compiler can
be sure that the formal parameter is not threatened by changes to the
actual, it can omit the copy.

Such an operation is not beyond a globally-optimizing compiler which can
see the whole of a module; however, it doesn't take care of inter-module
aliasing and problems.  A compiler which can use inter-module analysis
of such things is too far away, and is too overboard to implement for
this simple optimization.

Use compiler pragmas to inhibit the compiler from doing the copy,
but on your own head be it!



Sat, 17 Feb 1996 17:15:54 GMT  
 Read-only parameters

Quote:


>|>
>|> Clearly array value parameters are required for reasons of language
>|> orthogonality, but, as a practical software developer, I don't see uses galore
>|>

>[ Stuff deleted ]

>I'm sorry, but I don't agree with you one bit.  Don't add CONST and
>READONLY to Oberon-2 in respect of parameters.  They are not needed.

You are correct that they are not (strictly needed), you are not entirely
correct.  A compiler cannot always determine when it is safe to NOT copy
the source.  In the case, the compiler must take the safest method and
always make a copy.  The requested change is not intended as an
optiization opportunity for the compiler, but as a documentation aid for
the programmer.  Consider the following:

PROCEDURE StrongMagic(VAR x : SomeType);

Is x modified by this procedure, or passed as a VAR parm for efficiency?
If it were instead declared as:

PROCEDURE StrongMagic(VAR x-: SomeType);

You, the programmer using this procedure, would know that x is not
modified in any way BY THIS PROCEDURE.  Note that I am not calling the
parameter a constant, but a read/only value.  This does not place any
constraints on any other modification of the value of x, except in this
procedure (and all procedures called by it).  So, the aliasing problem
can still occur, but it is only slightly different than when it would
occur on a normal VAR parm.

The CONST parameter suggestion opens as many, or more, problems than it
solves, but a read/only VAR parameter has few objectionable qualities.

Taylor "My statements are R/O.  No disagreement allowed." Hutt
Always ask for a deck of cards when you fly.  Why not? They are free!



Sat, 17 Feb 1996 19:34:53 GMT  
 Read-only parameters

Quote:

>You are correct that they are not (strictly needed), you are not entirely
>correct.  A compiler cannot always determine when it is safe to NOT copy
>the source.  In the case, the compiler must take the safest method and
>always make a copy.  The requested change is not intended as an
>optiization opportunity for the compiler, but as a documentation aid for
>the programmer.  Consider the following:

This has got to be the worst paragraph that has ever come out of my editor...
I meant to say:

    You are corect that they are not (strictly) needed,
    but you are not entirely correct.  A compiler cannot
    always determine when it is safe to NOT copy the source
    parameter, in which case the compiler must use the safe
    assumption and always make a copy.

The rest of the paragraph remains the same.

Quote:

>Taylor "My statements are R/O.  No disagreement allowed." Hutt
>Always ask for a deck of cards when you fly.  Why not? They are free!

Taylor "Revisionism is a handy tool for history and news" Hutt
Mmmmm, donuts.... -- Homer Simpson


Sat, 17 Feb 1996 21:26:29 GMT  
 Read-only parameters

Subject: Re: Read-only parameters
Newsgroups: comp.lang.oberon


With all the problems with CONST and READONLY parameters
it is not surprizing that that they have been left out of Oberon.                                                            

Whitney
=====================================================

: Sorry, it can't. A read-only parameter could only be forwarded to a procedure that has
: also a 'CONST something: ARRAY OF CHAR' signature. After all, the feature works quite
: well in  -horresco referens- C++...

Isn't C/C++ the language that inspired the song
that goes...

There's a hole in my bucket dear Lizza, dear Lizza
.
Then fix it dear Henry, dear Henry..              
With what shall I fix it dear Lizza, dear Lizza
.                
The axe is dull dear Lizza, dear Lizza.
.
The cutting stone is dry dear Lizza, dear Lizza.
Then wet it dear Henry, dear Henry
With what shall I wet dear Lizza, dear Lizza.
With water dear Henry, dear Henry
.
There's a hole in my bucket dear Lizza, dear Lizza.

Whitney



Sat, 17 Feb 1996 22:22:50 GMT  
 Read-only parameters
Quote:



>>|>
>>|> Clearly array value parameters are required for reasons of language
>>|> orthogonality, but, as a practical software developer, I don't see uses galore
>>|>

>>[ Stuff deleted ]

>>I'm sorry, but I don't agree with you one bit.  Don't add CONST and
>>READONLY to Oberon-2 in respect of parameters.  They are not needed.

>You are correct that they are not (strictly needed), you are not entirely
>correct.  A compiler cannot always determine when it is safe to NOT copy
>the source.  In the case, the compiler must take the safest method and
>always make a copy.  The requested change is not intended as an
>optiization opportunity for the compiler, but as a documentation aid for
>the programmer.  Consider the following:

>PROCEDURE StrongMagic(VAR x : SomeType);

>Is x modified by this procedure, or passed as a VAR parm for efficiency?
>If it were instead declared as:

>PROCEDURE StrongMagic(VAR x-: SomeType);

  In the MAINSAIL language ( ALGOL -> SAIL -> MAINSAIL) there are
3 modifiers for a formal procedure parameter: USES, MODIFIES, PRODUCES.
These modifiers greatly aid legibility of program code.  USES makes
a copy (non VAR), MODIFIES (VAR) passes the parameter (pointer) with
the current value, and PRODUCES (VAR) passes the parameter (pointer)
but does not guarentee that it has any specific value (uninitialized).
Initialization is done within the procedure.
  These comments don't clarify the issue of this thread but I thought
you'all might be interested in an alternative view that has been
useful.
--
UMECORP, The creator of UME Voice
73 Digital Drive
Novato, CA 94949
pho (415) 883-1500, fax (415) 883-1711


Sun, 18 Feb 1996 00:24:12 GMT  
 Read-only parameters
|>
|>     You are corect that they are not (strictly) needed,
|>     but you are not entirely correct.  A compiler cannot
|>     always determine when it is safe to NOT copy the source
|>     parameter, in which case the compiler must use the safe
|>     assumption and always make a copy.
|>

I fail to see why you disagree with my original posting, where I said:

|> You're talking of dumb compilers which always copy the array on procedure
|> entry, regardless of the use which is made of it.  A good compiler can
|> determine when a copy needs to be made: if the parameter is not threatened
|> in any way, then no copy needs to be made.  Threatening can be from
|> aliasing, or from direct or indirect assignment.  If the compiler can
|> be sure that the formal parameter is not threatened by changes to the
|> actual, it can omit the copy.

I said that if a parameter is not threatened in any way, the compiler need
not make a copy.  Obviously, determining such threatening is a non-trivial
operation.  I agree, if there is the slightest doubt, the compiler should
copy it.  At present, Oberon compilers are not sufficiently advanced to do
any inter-module data flow analysis, and many won't do inter-procedural
analysis, either.  This is the gist of the second paragraph.

I fail to see why the compiler *must* use the safe assumption.  If the
compiler can guarantee that the parameter will never be aliased, it is
then quite at liberty to remove the copy.  For example:

  PROCEDURE Length(x: ARRAY OF CHAR): INTEGER;
    VAR i: INTEGER;
  BEGIN
    i := 0;
    WHILE x[i] # 0C DO
      INC(i)
    END;
    RETURN x
  END Length;

Here, the compiler can guarantee that x is never altered: no procedures
are called, no assignments to x are made, and there are no two parameters
which are open arrays.  Here, I would expect even a very simple compiler
to be able to spot that it really doesn't need to copy x.

What you're advocating is using VAR for run-time efficiency, and then marking
it read-only in order that you don't bow your foot off assigning to it.
Of course, as you say, it doesn't overcome the aliasing problem.

As an aside, consider the following example:

  TYPE
    VeryBig = ARRAY [0..32767] OF CHAR;  (* suitably large. *)

  PROCEDURE P(x: VeryBig);
    VAR i: CARDINAL;
  BEGIN
    (* Do something with `x', but don't alter it. *)
    i := x[0];
  END P;

Here, is it necessary for the compiler to pass `x' by value?  No, not
if we *always* pass such structures by reference, and let the called routine
(P, in this case) determine whether it needs to copy it or not.  Again,
such an optimization is simple to apply.  And, if it's simple, why don't
more compilers do it?

Of course, for the more difficult cases, we need the programmer to guide
the compiler.



Sun, 18 Feb 1996 00:21:35 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. reading serial parameters?

2. Reading Passed Parameters

3. Read-only parameters

4. Internal read from parameter

5. how to read a parameter from a normal text file

6. Reading Parameters...

7. can a modula2-program read command-line parameters?

8. BIOS harddrive read parameters

9. Reading parameters from the command line.

10. reading program line parameters?

11. Reading command line parameters

12. Reading command line parameters

 

 
Powered by phpBB® Forum Software