Re: Better control of assignment

[Craig Carey <research@ijs.co.nz>]

In this message I propose a way if importing package spec variables as
 being read-only even though they were not exported as being
 read-only.
Faster strings too.




On Tue, 13 Nov 2001 21:53:21 +1300, Craig Carey <research@ijs.co.nz>
wrote:

>On Sat, 10 Nov 2001 22:27:25 GMT, Jeffrey Carter <jrcarter@acm.org>
>wrote:
>>Nick Roberts wrote:
>>s only invoked for a copy (including parameter passing
>>> by copy (if selected)) from one variable object of type T to another. If
>>> this does not deliver enough control, you must make the type private. For
>>> example:
...
No need to make the type 'private' if there is a read-only feature
like what Oberon has.

>
>http://www-cse.ucsd.edu/classes/sp01/cse131B_A/oberon2.htm
...
>More on Modula-2: http://www.cetus-links.org/oo_oberon.html
...
>http://ooc.sourceforge.net/OOCref/OOCref_19.html
...
>|'245: This is imported read-only' 
>|
>|This applies to the left side of an assignment statement and to
>|variables passed to a VAR parameter as part of a procedure call.
>|This means that the destination variable (or designator) has to be
>|either
>|  1. imported as read-write (and no following selector accesses
>|       a read-only record field), or
>|  2. the value of a dereferenced pointer variable. 
>|Contrary to a pointer dereference, an element of a read-only array
>|is read-only, just like a field of a read-only record variable. 
>|
...

It seems that a record with both read-only and read-write fields,
and that is exported as being read-write, can be imported as being
read-only. That read-only importing overrides the read-write
exporting. That seems to Oberon feature that can be copied and
implemented with pragmas. It is 

Here is a quick proposed way of making imported package variables
be read only:

   package RW is
      X  : in out Integer;
   end RW;
   ---

   with RW;
   package P is
      package RO renames out RW;  --  Rename, make T2.* be read-only
      RO.X := 5;      --  illegal!, can use RW.X to get write access
   end P;

---

>subprocedures in its package], and the right hand side can be written
>to (pointers swapped) even though an "in" mode parameter [this last
>may need to be checked].

That is wrong (the fields of an "in" mode record parameter do not get
copied back to the caller, and presumably that is not going to be
altered).

Hence the improved fast Strings package with no use of private may
need to have pointers to pointers even in the distant future.

Here is fragment of a new spec file. This thread has been useful since
it got to conclude the pointers to pointers seem to be needed.


package Strings_Unlimited is
      --  Note: duplicating pointers may lead to faulty behaviour
      --  The arrival of read-only or limited pointers can lead to
      --   a fix.
   type String_Access is access all String;
   type String_Access_Ptr is access constant String_Access;

   Null_String_Access      : aliased constant String_Access :=
                                 new String (1 .. 0);
   Null_String_Access_Ptr  : aliased constant String_Access_Ptr :=
                                 Null_String_Access'Access;

   type Unlimited_String is
      limited record
         Ref         : String_Access_Ptr := Null_String_Access_Ptr;
         Len         : Natural := 0;
      end record;
   ...
end Strings_Unlimited;

I would have some code implementing this package once it is checked
and/or debugged. I wonder how the US military gets on with those
slow Strings.

Pointer copying could also be stopped by allowing pointer types to be
"limited". What a interesting finding: Oberon-2 is a better than
Ada 95 in sime areas.