Re: 'Protected' abstract subprograms

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Hmm, of course they can and do. Do you mean legality of public part not
> depending on the legality of private parts? Even they do.

I think the principle is:

    The private part cannot affect the legality of clients.

It seems like a good principle, but it is violated all over the place.
Search for "see 12.3" in the RM to find a bunch.  For example:

    generic
       type Formal is tagged limited private;
    package A is
    private
       task type T;
       type Derived is new Formal with record
         Limited_Component: T;
       end record;
    end;

    with A;
    package B is
       type Actual is tagged null record;
       package Instance is new A(Actual);
    end;

Package B is illegal, because of something going on the private
part of A -- without Limited_Component it would be legal.
With Limited_Component, B.Instance.Derived is a nonlimited type
with a limited component, which is illegal.

I think maybe this is an indication that Ada's macro-expansion model
of generics is a wrong approach.

> Yep, that's what I meant under "cooperative" privacy. For many
> applications, and the number of is growing rapidly, a "non-cooperative"
> privacy is needed as well.

Well, in a language that allows Unchecked_Conversion, address clauses,
machine code inserts, etc., I don't see any way to achieve
non-cooperative privacy within a single process.  You can achieve it
in Ada via remote procedure calls, though.

> Just one trivial example of slack privacy. You cannot hide default values:
> 
>    type T is private;

If you have:

    function V return T;

then the default value is hidden.

>    procedure Foo (X : T := V);
> private
>    type T is ...
> 
> Should have been something like:
> 
>    type T is private;
>    procedure Foo (X : T := <>); -- The value is deferred
> private
>    type T is ...
>    for Foo'Default (X) use V; -- Here it is, whichever syntax you prefer

I don't see a need for any such feature.

- Bob