Re: 'Protected' abstract subprograms

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

"Randy Brukardt" <randy@rrsoftware.com> writes:

> But Adam's point still holds: with enough ability to qualify the actuals, 
> these rules aren't needed.

Sure.  And my point was that without a complete change in the way
generics work, that would require dozens of additional contractual
specifications.

> I forget the exact case, but I recall something like that fairly recently --  
> we wanted to require some property to match on generic formals, but then 
> many generics would have to be duplicated in order that they would work both 
> with and without that property. (Was it predicates? Can't remember anymore.) 
> To really get proper working, you have to have "with property", "without 
> property", and "don't care about property", but of course the latter brings 
> up the legality issues again.

I'm not sure what property you're referring to, but "limited" is such a
property.  E.g., you'd like to have Ada.Containers.Vectors contain a
Vector type that is limited if and only if the element type is limited.
It works for arrays, but it doesn't work for vectors.  There are other
cases like that -- e.g. you'd like to be able to say that Vector is
derived from Sortable if and only if the Element_Type has relevant
comparison ops.

> In any case, when I was talking about Ada taking privacy seriously, I wasn't 
> thinking about (or caring about) generic instantiation. There is no real 
> privacy for generic specifications, nor can there be (at least with the 
> model of instantiation that Ada uses). [After all, Ada essentially has 
> special rules for the meaning of Legality Rules in generic units - those 
> override all other language principles, whether or not that is a good idea.] 
> Privacy only really matters for concrete things like packages or instances 
> of generic packages.

Right.  That's (part of) why I think the macro expansion model is wrong.
We pretend that the instance is actually there, and complain about
illegalities in its private part, as if those are the fault of the
person who wrote the instantiation (when in fact, that person did NOT
write that private part).

> My point was that that doesn't allow pricavy breaking (for Legality Rules) 
> within normal packages. I can't think of any exceptions to that - there 
> probably is one that I've forgotten but I doubt it invalidates the point.

The only case I know of where the code in a package private part can affect the
legality of code outside that package is this:

    package Recursive_Types is

       type T1 is private;

       package Nested is
          type T2 is private;
       private
          type T2 is record
             X: T1;
          end record;
       end Nested;

    private
       type T1 is record
          Y: Nested.T2; -- Illegal!
       end record;
    end Recursive_Types;

You're not allowed to have two records that are mutually recursive
like that.  So the legality of T1 depends on the code in Nested's
private part.

But one might argue that this case doesn't count, because there's
no separate compilation here.  You can't get this effect if Nested
is changed to a library unit.

- Bob