Re: Run-time accessibility checks

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 10 Dec 2008 18:55:41 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:txbc0ucekvix.ntpy85qsan7h$.dlg@40tude.net...
>> On Fri, 5 Dec 2008 19:42:40 -0600, Randy Brukardt wrote:
> ...
>>> I think that I might be able to fix the problem in the context of the
>>> containers only, and for dereference of the objects only, but it is not
>>> clear that the fix is worth the effort.
>>
>> It certainly does not. IMO Ada needs "setters" with the syntax sugar of an
>> assignment, it does not need outward access types. The whole idea is just
>> not Ada.
> 
> Well, I've thought about that, but I don't see a decent way to describe 
> read/write semantics other than with an access type. Specifically, I was 
> trying to figure out a user-defined dereference operation. One would presume 
> that we would use an operator function for that, but what would it look 
> like? The obvious answer of:
> 
>     function "all" (Obj : in Some_Type) return access Some_Other_Type;
> 
> has the accessibility issues. And something like:
> 
>    function "all" (Obj : in Some_Type) return Some_Other_Type;
> 
> means that you have (usually) copy semantics and in any case no assignment 
> into. That doesn't really fix anything.

No, you cannot solve it this way. A referential type (Some_Type) has to be
related to the target type (Some_Other_Type). Your first solution is to
replace one referential type with another built-in type (access
Some_Other_Type), that obviously does not change the semantics. Your second
solution is to replace it by the target type itself, no wonder that you
need a copy for that.

My solution is inheritance, disliked so much. If you want a referential
type to be a substitute for the target type, then the referential type
simply must  inherit to the target. (We don't need "all", though it can be
preserved using some intermediate referential type.) So the only thing
needed is interface inheritance from concrete types:

   type Ref_Type is private new Target_Type with private;

"private new" tells that only the interface of Target_Type is inherited,
the implementation is provided anew:

private   -- Privately it is just a plain pointer:
   type Ref_Type is access all Target_Type;

Because Ref_Type is not abstract, you will have to override all primitive
operations of Target_Type, and assignment must be a primitive operation,
and components getter/setters of, in case Target_Type were a record type,
must be as well.

> You certainly can't have a procedure ":=" to do assignment in because of 
> discrimant-dependent components.

":=" is a statement. What I would do is to define *two* primitive
subprograms the compiler will use in order to compose *one* ":=". The first
operation will determine the discriminants, the second will continue with
those known.

> I suppose you could have a component setter, but that requires a procedure 
> with two names:
> 
>     procedure <component>.":=" (Target : in out Some_Tagged_Type; Source : 
> in Some_Other_Type);
> 
> which would then be used as:
> 
>     Target.<component> := Source;

This is what I call abstract record interface. For each component it will
have two operations:

   function ".<component>" (R : Abstract_Record_Type)
      return Component_Type is abstract;
   procedure ".<component>"
      (R : in out Abstract_Record_Type; C : Component_Type) is abstract;

The compiler uses the second (setter) for all LHS X.Component.

> But that looks like a giant change to the Ada models, almost certainly out 
> of scope for this current round. And it certainly means no useful iterators. 

Records are not iterated. If we want a container to support iterations,
that must be an abstract array. It also was getter and setters:

   function "()" (A : Abstract_Array_Type; I : Index_Type)
      return Element_Type is abstract;
   procedure "()"
      (A : in out Abstract_Array_Type; I : Index_Type; E : Element_Type)
         is abstract;

> And it also isn't very flexible -- where does the Cursor of a container go??

To me to the recycle bin. *BUT* there is no any problem with cursors,
absolutely. A cursors is a pair. The first component is a type derived from
the container's interface (a reference to the container), the second
component is the container's index. Done!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de