Version 1.2 of acs/ac-00123.txt

Unformatted version of acs/ac-00123.txt version 1.2
Other versions for file acs/ac-00123.txt

!standard 7.1(6)          05-10-24 AC95-00123/01
!class Amendment 05-10-24
!status received no action 05-10-24
!status received 05-10-14
!subject The "not private" part
!summary
!appendix

From: Tucker Taft
Date: Friday, October 14, 2005  7:27 AM

Here is one of those last-minute ideas that
everybody hates...

---

The only real regret I have had in the Ada 2005 process has been our
inability to support the instantiation of signature generics
with private types.  The usefulness of signatures goes up
significantly if a generic package can include within itself
an instantiation of a signature package.  See below for an example.

In any case, I came up with what seems like a very simple solution
to the problem, allow a (generic) package spec to have a "not private"
section.

E.g.

    [generic
        ....]
    package P is
        type T is private;
        ...
    private
        type T is ...
        ...
    not private
        package Sig is new Generic_Signature(T, ...);
        ...
    end P;

I realize it is awfully "late in the day," but is there any
sympathy to allowing this "not private" indication in a (generic)
package spec?  Famous last words, but this seems like a very
simple implementation problem, given that compilers already
have to support nested packages with their own private
part.

Comments?  Slings and Arrows?

----------


Here is an example of use:


    generic
        type Element is private;
        with function Equivalent(Left, Right : Element) return Boolean is <>;
        type Set is private;
        with function Union(Left, Right : Set) return Set is <>;
        with function Intersection(Left, Right : Set) return Set is <>;
        with function Unit_Set(Elem : Element) return Set is <>;
        with function Is_Empty(S : Set) return Boolean is <>;
        ...
    package Set_Signature is end;  -- A set "signature" generic


    with Set_Signature;
    generic
         type Element is private;
         ...
    package Fancy_Sets is
         -- a particular generic sets package
         type Set is private;
         function Union(Left, Right : Set) return Set;
         ...
    private
         type Set is ...
         ...

    not private

         -- Provide instantiation of signature to show how package matches set signature
         package Signature is new Set_Signature(Element, Equivalent, Set, Union, Intersection, ...);
    end Fancy_Sets;

    generic
        type Item is private;
        with package Sets is new Set_Signature(Element => Item, otheres => <>);
           -- Will accept any set package that satisfies the signature
        ...
    package Some_Abstraction_Needing_Sets is ...


    package Fancy_Int_Sets is new Fancy_Sets(Integer, ...);
      -- instantiation of the fancy sets package

    package Inst is new Some_Abstraction_Needing_Sets(
      Item => Integer, Sets => Fancy_Int_Sets.Signature, ...);
        -- Instantiation of some abstraction that needs a set

****************************************************************

From: Bob Duff
Date: Friday, October 14, 2005  8:35 AM

> In any case, I came up with what seems like a very simple solution
> to the problem, allow a (generic) package spec to have a "not private"
> section.

Tucker will no doubt be tarred and feathered for this last-minute
proposal.  ;-)

For what it's worth, I agree that this is a serious language problem,
and I agree that Tucker has found a simple solution.

Tuck, if you're going to get anywhere with this, I imagine you'll need
to produce exact RM wording as soon as possible.

****************************************************************

From: Pascal Leroy
Date: Friday, October 14, 2005  9:02 AM

> Here is one of those last-minute ideas that
> everybody hates...

Not a chance at this late date.

Furthermore, I am not interested in solving specifically the problem of
signatures.  If this problem is worth solving (I think it is) the solving
must be applicable to non-trivial generics.

I also have a hunch that this would lead to privacy leaking in the
presence of boxy formal packages.

****************************************************************

From: Bob Duff
Date: Friday, October 14, 2005  9:53 AM

> Not a chance at this late date.

:-(

> Furthermore, I am not interested in solving specifically the problem of
> signatures.

I agree.  I never understood why Tuck focuses so much on signatures --
regular old generics have the same problem, and are more common.

>...If this problem is worth solving (I think it is) the solving
> must be applicable to non-trivial generics.

I think it would solve that, too, would it not?  The problem is that Ada
ties both visibility and elaboration order to the textual order of the
program, requiring all the visible stuff to precede the private stuff.
Tuck's suggestion neatly fixes that.

> I also have a hunch that this would lead to privacy leaking in the
> presence of boxy formal packages.

Hmm.  Could you explain that?

I would think Tuck's suggestion would have a rule saying the private
part is not visible in the not-private part.  Just like a parent's
private part is not visible in the visible part of a visible child.
Is that right, Tuck?

****************************************************************

From: Pascal Leroy
Date: Friday, October 14, 2005  10:11 AM

> I would think Tuck's suggestion would have a rule saying the
> private part is not visible in the not-private part.  Just
> like a parent's private part is not visible in the visible
> part of a visible child. Is that right, Tuck?

Then I misunderstood Tuck's proposal and I don't see how it would be
better than just declaring a child:

	package P.Sig is new Generic_Signature (T, ...);

Furthermore, I don't see how this helps with the case where you want T to
contain a pointer to a vector-of-T defined by an instantiation of a
generic.

I guess that I would need to see wording to understand what's going on in
Tuck's brain.  But at any rate, this is for Ada 2019, not for Ada 2005
(John pointed out that he'll be 82 in 2019 ;-)

****************************************************************

From: Robert Dewar
Date: Friday, October 14, 2005  10:37 AM

Seems too big a change for last minute to me.

****************************************************************

From: Stephen W Baird
Date: Friday, October 14, 2005  12:21 PM

> Then I misunderstood Tuck's proposal and I don't see how it would be
> better than just declaring a child:
>
>    package P.Sig is new Generic_Signature (T, ...);

It would be a little bit clunkier than that because a child unit of a
generic package must itself be a generic unit (RM95 10.1.1(17)).

Thus, the child unit would have to be something like

      generic
      package P.Sig_Generic is
        package Sig is new Generic_Signature (T, ...);
      end Sig_Generic;

and the client would have to instantiate it in order to get the signature.

Awkward, but it almost captures the semantics Pascal was trying for.

I say "almost" because now two clients of a given instance of the parent
generic would refer to two different instances of the signature generic.

In the case of a signature generic, this might not make much difference
(although one could certainly construct cases where it would).

In the more general case where the generic being instantiated in the child
unit has state, this difference could become more important.

I think Tuck's proposal (which I agree is too big a change at this point)
would address this problem.

****************************************************************

From: Randy Brukardt
Date: Friday, October 14, 2005  2:00 PM

> Here is one of those last-minute ideas that
> everybody hates...

Yes, I hate both the idea and the fact that it is last minute. Getting
visibility "back" in the same unit would require some very different
approach to visibility in our compiler.

I agree with everyone at this point that there is no room for "ideas".
Indeed, there is no room for anything unless it is fixing a clear bug, or
its just a wording improvement. After all, the thing is going to be finished
in the next week or so.

Anyway, I do agree with Tucker that this is the one of the most important
problems that we didn't solve. I certainly regret that Pascal insisted on
killing the proposal for partial instantiations just as we were getting it
worked out. I know Tucker was willing to make another attempt to figure out
rules to address the problems that Erhard and Steve had identified, and I
think that there was a decent chance that those issues could have been
worked out. We certainly could have killed it at the next meeting if that
didn't turn out to be the case. Certainly, doing so wouldn't have had any
significant impact on the *real* delivery date of the standard.

Anyway, that's water under the dam at this point.

****************************************************************

From: Robert Dewar
Date: Friday, October 14, 2005  5:48 PM

> Anyway, I do agree with Tucker that this is the one of the most important
> problems that we didn't solve. I certainly regret that Pascal insisted on
> killing the proposal for partial instantiations just as we were getting it
> worked out. I know Tucker was willing to make another attempt to figure out
> rules to address the problems that Erhard and Steve had identified, and I
> think that there was a decent chance that those issues could have been
> worked out. We certainly could have killed it at the next meeting if that
> didn't turn out to be the case. Certainly, doing so wouldn't have had any
> significant impact on the *real* delivery date of the standard.

There's nothing to stop us adding new features to the language
after the standard is out. What's important is what's in
implementations, not what's in the standard per se.

We have added many important features after the fact of the
standard (e.g. 8 bit chars in Ada 83, unchecked_union in Ada 95).

> Anyway, that's water under the dam at this point.

I don't see any reason to close off debate on the issue, I agree
it is too late for the new standard.

****************************************************************

From: Bob Duff
Date: Friday, October 14, 2005  6:53 PM

> There's nothing to stop us adding new features to the language
> after the standard is out. What's important is what's in
> implementations, not what's in the standard per se.

Yes, indeed.

****************************************************************

From: Tucker Taft
Date: Friday, October 14, 2005  8:43 PM

I focused on signatures, but a "not private" part
allows regular generics to be instantiated in the
same package as the private type.  It also allows
you to declare visible variables of a private type,
for what that's worth.  It helps with the Vector-of-T
problem, though it was pointed out that there is
a fundamental privacy issue with vector-of-T of whether
it contains a component of type T, or only pointers
to such objects.

I don't see any privacy leakage possibilities.

I'll write up wording for the "fun" of it anyway,
recognizing that it is probably for posterity only.

****************************************************************

From: John Barnes
Date: Friday, October 14, 2005  12:38 PM

I suggested this to Jean in about 1983 but he ignored it. Linear
elabortation always seems to get in the way of privacy and I thought it
would be useful to switch your privacy on and off as much as you like. Now
you see it now you don't.

****************************************************************

From: Pascal Leroy
Date: Monday, October 17, 2005  1:26 AM

> I certainly
> regret that Pascal insisted on killing the proposal for
> partial instantiations just as we were getting it worked out.
> I know Tucker was willing to make another attempt to figure
> out rules to address the problems that Erhard and Steve had
> identified, and I think that there was a decent chance that
> those issues could have been worked out.

Amusingly enough, this is not my recollection of how things turned out at
the Atlanta meeting last year.  The way I remember it, the problem seemed
uglier and uglier the more we looked at it.  The minutes have, near the
end of the discussion of AI 359: "There is general consternation from the
group" ... "Randy thinks that this proposal isn't mature enough to put in
at this point" ... "we aren't clear enough on the solution".

Anyway, I certainly don't regret making this decision.  We have exceeded
our schedule by 6 months just trying to polish the RM and to make things
consistent.  The last thing we needed were half-baked ideas interfering
with the process.

****************************************************************

From: Robert I. Eachus
Date: Monday, October 17, 2005  4:48 PM

>  Anyway, I certainly don't regret making this decision. We have
> exceeded our schedule by 6 months just trying to polish the RM and to
> make things consistent. The last thing we needed were half-baked ideas
> interfering with the process.

Agreed.  I see several possible ways to address this issue, at least in
terms of syntactic sugar.  Just to put one on the table, consider:

   * package* Foo *is new generic* Bar;

with the actual instantiation deferred into the private part.  (This is
not a complete example or proposal, for example should the generic
parameters appear in this part as well as in the private part?  Not
having the generic parameters outside the private part actually allows
more flexibility. I asume that there would be no difficulties
added--since the point of instantiation would be deferred to the private
part, the instance could not be referred to before then anyway.)

A different idea would be to have *not private* apply to the following
declaration only instead of to a textual scope.

The way standarization should work is for some compiler to implement
some such extension.  When there has been real world experience with the
feature, then it can be added to the standard.  (If no one is willing to
pay to implement it?  That is a data point as well.)

****************************************************************

From: Randy Brukardt
Date: Monday, October 17, 2005  10:08 PM

> Amusingly enough, this is not my recollection of how things turned out at
> the Atlanta meeting last year.  The way I remember it, the problem seemed
> uglier and uglier the more we looked at it.  The minutes have, near the
> end of the discussion of AI 359: "There is general consternation from the
> group" ... "Randy thinks that this proposal isn't mature enough to put in
> at this point" ... "we aren't clear enough on the solution".

I think that was more momentary frustration with the process than a sound
technical decision.

> Anyway, I certainly don't regret making this decision.  We have exceeded
> our schedule by 6 months just trying to polish the RM and to make things
> consistent.  The last thing we needed were half-baked ideas interfering
> with the process.

The solution was quite well baked by Atlanta; Tucker just had gone a bit too
far on what was allowed. I'm completely confident that the problems could
have been worked out - certainly a limited view of the instance would have
worked - the only remaining question was whether anything more could be
allowed. And certainly the issues pointed out in Atlanta suggested that the
answer was no. But even a limited view would be quite useful, especially
combined with the "normal" view seen by clients of a package.

Anyway, I don't think it would have had much impact on the schedule, because
either it would have worked by Paris, or it would have been gone. And it was
very close to working.

This is one area where I don't think vendor experiments will be very useful.
Vendors are going to implement something that (1) works for their
customer(s) and (2) is easy for their implementation. Can't argue with (1),
of course. But what we found out during the work on this idea was that the
different vendors implementations of generics are different enough that what
is easy for one vendor is near impossible for others. I would hope that
anyone that intends to seriously look at the problem would read all of the
359 AIs and e-mail, but I have my doubts that any vendor-designed solution
would work for the Ada *language*, rather than just that vendor.

****************************************************************



Questions? Ask the ACAA Technical Agent