Problem with limited with

Problem with limited with

[Simon Wright]

A poster on Stack Overflow[1] has a problem with mutually recursive
types. The essence to the problem is here:

   limited with Pak2;
   package Pak1 is
      type Pak2_T2_P is access all Pak2.T2;
      task type T1 is
         entry E1 (T2 : Pak2_T2_P);
      end T1;
   end Pak1;

   package Pak2 is
      task type T2 is
         entry E2;
      end T2;
   end Pak2;

   with Pak2;
   package body Pak1 is
      task body T1 is
         The_T2 : Pak2_T2_P;
      begin
         accept E1 (T2 : Pak2_T2_P) do
            The_T2 := T2;
         end E1;
         The_T2.E2;             --  compilation fails
         The_T2.all.E2;         --  compilation succeeds
      end T1;
   end Pak1;

The compiler's error message is
   invalid prefix in selected component "The_T2"
   dereference must not be of an incomplete type (RM 3.10.1)

I can see from 3.10.1(2.2) [2] that the dereference might be incomplete
- but (2.4) seems to say it should be OK.

I note that all the examples of using limited with use anonymous access
types, which can't be used as entry parameters; if I replace
   task body T1 is
      The_T2 : Pak2_T2_P;
   begin
by
   task body T1 is
      The_T2 : access Pak2.T2;
   begin
then the compilation succeeds.

Does this look like a GNAT bug?

[1]
http://stackoverflow.com/questions/17869802/using-limited-with-in-ada-to-avoid-circular-dependency
[2]
http://www.adaic.org/resources/add_content/standards/12rm/html/RM-3-10-1.html#p2.2

Re: Problem with limited with

[Jeffrey Carter]

On 07/26/2013 12:14 PM, Simon Wright wrote:
>
>     limited with Pak2;
>     package Pak1 is
>        type Pak2_T2_P is access all Pak2.T2;
>        task type T1 is
>           entry E1 (T2 : Pak2_T2_P);
>        end T1;
>     end Pak1;
>
>     package Pak2 is
>        task type T2 is
>           entry E2;
>        end T2;
>     end Pak2;
>
>     with Pak2;
>     package body Pak1 is
>        task body T1 is
>           The_T2 : Pak2_T2_P;
>        begin
>           accept E1 (T2 : Pak2_T2_P) do
>              The_T2 := T2;
>           end E1;
>           The_T2.E2;             --  compilation fails
>           The_T2.all.E2;         --  compilation succeeds
>        end T1;
>     end Pak1;

The best solution is to avoid limited with:

with Pak2;
package Pak1 is
    task type T1 is
       entry E1 (T2 : Pak2.T2);
    end T1;
end Pak1;

package body Pak1 is
    task body T1 is
    begin
       accept E1 (T2 : Pak2.T2) do
          T2.E2;
       end E1;
    end T1;
end Pak1;

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: Problem with limited with

[Adam Beneschan]

On Friday, July 26, 2013 1:49:08 PM UTC-7, Jeffrey Carter wrote:
> On 07/26/2013 12:14 PM, Simon Wright wrote:

> The best solution is to avoid limited with:

No, the best solution is to not write these packages at all, since it's obvious that Simon's code doesn't do anything useful.

C'mon, people.  It should be possible to ask a question about the language rules by posting a reduced case, without getting comments about why the poster didn't write his code a different way, or why the identifiers aren't descriptive, or why a complete working example wasn't posted or something.  There seems to have been an increase in the number of this sort of unhelpful answer in recent months, and I'm getting pretty frustrated.  Obviously this case is reduced from a larger case where LIMITED WITH *was* needed (and that would be obvious to me even if I hadn't seen the original example on stackoverflow).

And by the way--yes, it does look like a GNAT bug.

                             -- Adam

Re: Problem with limited with

[Shark8]

On Friday, July 26, 2013 4:17:32 PM UTC-6, Adam Beneschan wrote:
> On Friday, July 26, 2013 1:49:08 PM UTC-7, Jeffrey Carter wrote:
> 
> > On 07/26/2013 12:14 PM, Simon Wright wrote:
> 
> 
> 
> > The best solution is to avoid limited with:
> 
> 
> 
> No, the best solution is to not write these packages at all, since it's obvious that Simon's code doesn't do anything useful.
> 
> 
> 
> C'mon, people.  It should be possible to ask a question about the language rules by posting a reduced case, without getting comments about why the poster didn't write his code a different way, or why the identifiers aren't descriptive, or why a complete working example wasn't posted or something.  There seems to have been an increase in the number of this sort of unhelpful answer in recent months, and I'm getting pretty frustrated.  Obviously this case is reduced from a larger case where LIMITED WITH *was* needed (and that would be obvious to me even if I hadn't seen the original example on stackoverflow).
> 
> 
> 
> And by the way--yes, it does look like a GNAT bug.
> 
> 
> 
>                              -- Adam

You are correct; it is annoying.
I came across an interesting case where (using limited with) using an actual type in a parameter resulted in it being uncompilable and had to use anonymous-access as the parameter instead. (Of course I excluded null, as these functions would be meaningless w/o access to that parameter -- but it would have been nicer to simply have the parameter be the actual type.)

Re: Problem with limited with

[Simon Wright]

Adam Beneschan <adambeneschan@aol.com> writes:

> And by the way--yes, it does look like a GNAT bug.

Thanks, Adam.

Re: Problem with limited with

[Jeffrey Carter]

On 07/26/2013 03:17 PM, Adam Beneschan wrote:
>
> C'mon, people.  It should be possible to ask a question about the language
> rules by posting a reduced case, without getting comments about why the
> poster didn't write his code a different way, or why the identifiers aren't
> descriptive, or why a complete working example wasn't posted or something.

It should be possible to post a reduced example that actually uses the feature
that causes the problem.

But even in that case, I'd still say the best solution is to avoid limited with.
Recursive types belong in the same pkg together. Limited with is a kludge to let 
people write JavAda and should never have been added in the 1st place.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: Problem with limited with

[Adam Beneschan]

On Friday, July 26, 2013 5:17:21 PM UTC-7, Jeffrey Carter wrote:
> On 07/26/2013 03:17 PM, Adam Beneschan wrote:
> 
> >
> 
> > C'mon, people.  It should be possible to ask a question about the language
> > rules by posting a reduced case, without getting comments about why the
> > poster didn't write his code a different way, or why the identifiers aren't
> > descriptive, or why a complete working example wasn't posted or something.
> 
> It should be possible to post a reduced example that actually uses the feature
> that causes the problem.

As someone who often tries to answer (and sometimes asks) questions involving language rules, I only want to see the parts of the code that are relevant to the language-law question--even if that results in an example that (by itself) would be useless in real life.  But adding other stuff just gets in the way.  

                                -- Adam

Re: Problem with limited with

[Shark8]

On Friday, July 26, 2013 6:17:21 PM UTC-6, Jeffrey Carter wrote:
> 
> But even in that case, I'd still say the best solution is to avoid limited with.
> Recursive types belong in the same pkg together. Limited with is a kludge to let 
> people write JavAda and should never have been added in the 1st place.

Hm, interesting assertion. The place I mentioned before is a little FORTH interpreter I was working on ( https://github.com/OneWingedShark/Forth ) so that Forth.VM (the package containing the VM/interpreter) and Forth.Types (the package containing the data-types [for cells] and cell-operations) could be mutually dependent:
    -- Routine is an access to a procedure; this cannot be put into a
    -- subpool, sadly, and is intended only for definition of words;
    -- typically, the routines pointed to should have full view of the
    -- VM (that is the stacks) in order to manipulate them.
    Type Routine is Access Procedure( State : not null access Forth.VM.Interpreter );


Is that a bad design-choice? If so, why?

Re: Problem with limited with

[Randy Brukardt]

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:ksv36l$tnc$1@dont-email.me...
> On 07/26/2013 03:17 PM, Adam Beneschan wrote:
>>
>> C'mon, people.  It should be possible to ask a question about the 
>> language
>> rules by posting a reduced case, without getting comments about why the
>> poster didn't write his code a different way, or why the identifiers 
>> aren't
>> descriptive, or why a complete working example wasn't posted or 
>> something.
>
> It should be possible to post a reduced example that actually uses the 
> feature
> that causes the problem.
>
> But even in that case, I'd still say the best solution is to avoid limited 
> with.
> Recursive types belong in the same pkg together. Limited with is a kludge 
> to let people write JavAda and should never have been added in the 1st 
> place.

I don't buy this. In a large system, it's very common to have types which 
are mutually related. If one is forced to put all such types into a single 
package specification, a large part of the entire system ends up in one 
giant package. And that eliminates a lot of Ada's advantages about reduced 
coupling and the ability to have multiple people working on a system without 
tripping over each other.

The Claw Builder ran into this problem in spades. The effort to avoid 
recursion was so severe that we essentially stopped working on it waiting 
for the ARG to decide how to handle the problem. The need to have types 
associated with both the generated code structure and with the structure of 
the application (and these are only slightly related) absolutely requires 
some sort of recursion system.

(And I don't know that much about Java -- I've never used it.)

                                           Randy.

Re: Problem with limited with

[Jeffrey Carter]

On 07/26/2013 07:32 PM, Shark8 wrote:
>
> Is that a bad design-choice? If so, why?

Certainly. It uses anonymous types and visible access types, both Bad Ideas.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: Problem with limited with

[Simon Wright]

Adam Beneschan <adambeneschan@aol.com> writes:

> On Friday, July 26, 2013 5:17:21 PM UTC-7, Jeffrey Carter wrote:
>> On 07/26/2013 03:17 PM, Adam Beneschan wrote:
>> 
>> > C'mon, people.  It should be possible to ask a question about the
>> > language rules by posting a reduced case, without getting comments
>> > about why the poster didn't write his code a different way, or why
>> > the identifiers aren't descriptive, or why a complete working
>> > example wasn't posted or something.
>> 
>> It should be possible to post a reduced example that actually uses
>> the feature that causes the problem.
>
> As someone who often tries to answer (and sometimes asks) questions
> involving language rules, I only want to see the parts of the code
> that are relevant to the language-law question--even if that results
> in an example that (by itself) would be useless in real life.  But
> adding other stuff just gets in the way.

I was modelling my example on Adam's style!

Re: Problem with limited with

[Shark8]

On Friday, July 26, 2013 11:42:27 PM UTC-6, Jeffrey Carter wrote:
> On 07/26/2013 07:32 PM, Shark8 wrote:
> >
> > Is that a bad design-choice? If so, why?
> 
> Certainly. It uses anonymous types and visible access types, both Bad Ideas.

To be fair, the ONLY reason I have to use anonymous access types at all there is because GNAT chokes up when I try to use the type itself. (I think there's a comment to that effect elsewhere.)

Re: Problem with limited with

[Jeffrey Carter]

On 07/27/2013 09:00 AM, Shark8 wrote:
>
> To be fair, the ONLY reason I have to use anonymous access types at all there
> is because GNAT chokes up when I try to use the type itself. (I think there's
> a comment to that effect elsewhere.)

About the only thing you can do with limited with is declare access types 
designating the types in the withed pkg, So of course an Ada compiler complains 
if you try to do anything else. When you avoid visible access types, you 
naturally avoid limited with. This is how I've been able to work on large 
projects (> 1000 pkgs) without a single limited with.

-- 
Jeff Carter
"This trial is a travesty. It's a travesty of a mockery of a
sham of a mockery of a travesty of two mockeries of a sham. ...
Do you realize there's not a single homosexual on that jury?"
Bananas
27

Re: Problem with limited with

[Simon Wright]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> About the only thing you can do with limited with is declare access
> types designating the types in the withed pkg, So of course an Ada
> compiler complains if you try to do anything else. When you avoid
> visible access types, you naturally avoid limited with. This is how
> I've been able to work on large projects (> 1000 pkgs) without a
> single limited with.

I had a project of similar size, in Ada 95 - so limited with wasn't an
option! (I did try the GNAT experimental versions, but each subtle
variant in my code produced a new ICE).

The solution was threefold:

(a) each class (this was code-generated from a UML model using
a Shlaer-Mellor OOA profile) declares a type Instance derived from a
base type

(b) associations (what you would need the limited with for) are
implemented by appropriate access components in the Instance record
(they aren't private, but you're not supposed to use them)

(c) associations between two classes are managed using a third
package. If the House_Management model says

   Association A1:
      each Button Controls one-or-more Lamps
      each Lamp Is_Controlled_By one-or-more Buttons

the generated code will include

   with House_Management.Lamp.Collections;
   with House_Management.Button.Collections;
   with House_Management.Button_To_Lamp.Collections;
   private package House_Management.A1 is

      function Link
        (Controls : Lamp.Handle;
         Is_Controlled_By : Button.Handle)
        return Button_To_Lamp.Handle;

   [...]

      procedure Unlink
        (Button_To_Lamp_Handle : Button_To_Lamp.Handle);

   [...]

      function Controls
        (A_Lamp : Lamp.Handle)
        return Button.Collections.Collection;

   [...]

      function Is_Controlled_By
        (A_Button : Button.Handle)
        return Lamp.Collections.Collection;

Re: Problem with limited with

[Randy Brukardt]

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:kt0uo3$3kh$1@dont-email.me...
> On 07/27/2013 09:00 AM, Shark8 wrote:
>>
>> To be fair, the ONLY reason I have to use anonymous access types at all 
>> there
>> is because GNAT chokes up when I try to use the type itself. (I think 
>> there's
>> a comment to that effect elsewhere.)
>
> About the only thing you can do with limited with is declare access types 
> designating the types in the withed pkg, So of course an Ada compiler 
> complains if you try to do anything else.

Not true in Ada 2012. We realized that the language didn't need all of the 
restrictions on incomplete types that it had, and we removed a lot of them. 
See 3.10.1 and 13.14. The trick is that freezing a subprogram need not 
freeze the types of its profile -- that's only needed when there is a call 
or a body.

In particular, any incomplete type can be used as the name of a parameter so 
long as it is completed before the body of the subprogram is encountered. 
(The actual rules are a bit more complex than this, but this is the best way 
to think of it.) For limited with, this just means that a matching 
non-limited with has to be visible in the body of the package. As this is 
new, I can imagine that GNAT has bugs in this area. (I think the OP's code 
should compile, but I didn't check this in detail.)

The net effect is that you can use a type imported via a limited with 
without having any visible access types. (You can't have functions that 
return such types, or components, because those need to know more about the 
type than is available.)

                                                    Randy.