making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Mehdi Saada]

A generic package P1 is formal parameter of an other generic package P2. P2 has a (public) son. P1 is instanciated in the public part of P2's specifications. How can P1's son been granted access to exceptions declared in P1. Is it possible without instanciating P1 again ?
I'm starting to see how much a generic package generic formal parameter can behave differently from a normal "with"-ed one, non-generic package.

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> A generic package P1 is formal parameter of an other generic package
> P2. P2 has a (public) son. P1 is instanciated in the public part of
> P2's specifications. How can P1's son been granted access to
> exceptions declared in P1. Is it possible without instanciating P1
> again ?

Could you provide a simple example of your setup? I might be confused by
the unusual terminology - what do you mean by 'son'? Is it a child
package, or something else?

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Mehdi Saada]

Child package, right.
Sorry, seems like I mixed things up a bit.
My setup is below, but I think it's already done, and I misunderstood from mispelling the exception ("zero_division" instead of "zero_denominator". Stupid me.

with P1_G;
generic
   with package P1 is new P1_G(<>);
   Max : Positive;
package P2 is [...] end P2.
package body P2_G is [...] end P2_G;

generic
package P2_G.Child is [...] end P2_G.Child; -- child package
package body P2_G.Child
[...] -- I wanted exceptions declared in P1_G (or P1, I dont know the details here) to be visible here, but it OBVIOUSLY already the case.
end P2_G.Child.

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> Child package, right.
> Sorry, seems like I mixed things up a bit.

Easy enough to do when scrambling through this stuff!

> My setup is below, but I think it's already done, and I misunderstood
> from mispelling the exception ("zero_division" instead of
> "zero_denominator". Stupid me.
>
> with P1_G;
> generic
>    with package P1 is new P1_G(<>);
>    Max : Positive;
> package P2 is [...] end P2.
> package body P2_G is [...] end P2_G;
>
> generic
> package P2_G.Child is [...] end P2_G.Child; -- child package
> package body P2_G.Child
> [...] -- I wanted exceptions declared in P1_G (or P1, I dont know the
> details here) to be visible here, but it OBVIOUSLY already the case.

It would be P1.Exception_Name

> end P2_G.Child.

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Dmitry A. Kazakov]

On 2018-01-21 18:30, Mehdi Saada wrote:
> Child package, right.
> Sorry, seems like I mixed things up a bit.
> My setup is below, but I think it's already done, and I misunderstood from mispelling the exception ("zero_division" instead of "zero_denominator". Stupid me.
> 
> with P1_G;
> generic
>     with package P1 is new P1_G(<>);
>     Max : Positive;
> package P2 is [...] end P2.
> package body P2_G is [...] end P2_G;
> 
> generic
> package P2_G.Child is [...] end P2_G.Child; -- child package
> package body P2_G.Child
> [...] -- I wanted exceptions declared in P1_G (or P1, I dont know the details here) to be visible here, but it OBVIOUSLY already the case.
> end P2_G.Child.

For visibility you always use "use", which is logical, isn't it?

Now some remarks:

1. It is a bad idea to declare anything in a generic package which is 
not a subject parametrization. Exception is a simple value. It has 
nothing to seek in a generic. Especially because each instance of the 
generic will produce a new exception. Make a parent package instead:

    package My_Stuff is
       Baz : exception; -- One exception for all
    end My_Stuff;

    generic
       ...
    package My_Stuff.P1_G is ...

2. There are strange, if not outright stupid, rules about visibility of 
generic formal parameters in generic children. Strangeness of these 
rules is multiplied by compiler bugs infesting implementations of 
generics. Only a language lawyer call tell what is just an effect of 
these rules and what of the bugs. A pragmatical approach to resolve the 
mess without drowning there is to rename all stuff coming from the 
formals you would like to use later in children. E.g.

    generic
       with package P1_G is ...
    package P2 is
       Baz : exception renames P1_G.Baz; -- It won't get lost

3. Remember that Ada did visibility of renamings wrong. A renaming can 
hide the renamed object! So you must be careful if both original 
exception and its renaming become visible, you will see none. They hide 
each other.

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

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Mehdi Saada]

Thanks Dmitry. I just stumpled against another exemple of your point 1, RM's paragraph 11.2.8:
An exception_name of a choice shall not denote an exception declared in a generic formal package.

What ? Doesn't it make them almost useless, then ?! It doesn't accept things like
P1_instance.exception_name either, which I don't get at all. It should, if that rule ever was a concern about names hiding and such, your point 1 that is. How do I do to STILL use exceptions declared in generic package, in a handler ? I won't rewrite the package just for this. Each time I try, there's always more work than expected.

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Dmitry A. Kazakov]

On 2018-01-21 21:15, Mehdi Saada wrote:
> Thanks Dmitry. I just stumpled against another exemple of your point 1, RM's paragraph 11.2.8:
> An exception_name of a choice shall not denote an exception declared in a generic formal package.
> 
> What ? Doesn't it make them almost useless, then ?!

Consider the same exception visible under different names coming from 
the same package. The compiler could not decide that when compiling the 
exception handler. But you can use an exception from a generic instance 
still.

It is a general problem with generics that something legal when 
compiling it might turn legal or illegal depending on actual formal 
parameters. In some cases Ada just ignores that, e.g. by treating things 
wrongly or in an unexpected way, in other cases it tries to prevent 
that. It is an uphill battle. There is no way to fix 
generics/templates/macros.

> It doesn't accept things like P1_instance.exception_name either,
> which I don't get at all. It
> should, if that rule ever was a concern about names hiding and such,
> your point 1 that is. How do I do to STILL use exceptions declared in
> generic package, in a handler ? I won't rewrite the package just for
> this. Each time I try, there's always more work than expected.

The rule is too keep it as simple as possible. If there is any way to 
ditch generics, do it. Use interfaces and tagged types, mix-ins, 
class-wide access discriminants etc to achieve polymorphism.

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

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Mehdi Saada]

> But you can use an exception from a generic instance 
still. 
I thought so too ! Maybe I should, but I can't:
the exception handler "when P1.Zero_Denominateur => sth;"
raises:
P2_G.Child.adb:66:25: exception "Zero_Denominator" is declared in generic formal package
P2_G.Child.adb:66:25: and therefore cannot appear in handler (RM 11.2(8))

BUT: the said exception is NOT defined here, but in P1_G ->
generic
   with package P1 is new P1_G(<>); -- IN THERE
package P2_G is

>The rule is too keep it as simple as possible. If there is any way to ditch generics, do it. Use interfaces and tagged types, mix-ins, class-wide access discriminants etc to achieve polymorphism.

Eurg... From the little bit I read (and could understand), you're not very popular about this here... I'll rather follow the majority, besides, I do like the idea of generics. And one can ALWAYS find loopholes and flex a language beyond sense. Do you expect lawyers to be gods ?

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Mehdi Saada]

> But you can use an exception from a generic instance 
> still. 
I thought so too ! Maybe I should, but I can't:
the exception handler "when P1.Zero_Denominateur => sth;" raises:
P2_G.Child.adb:66:25: exception "Zero_Denominator" is declared in generic formal package
P2_G.Child.adb:66:25: and therefore cannot appear in handler (RM 11.2(8))
BUT: the said exception is NOT defined here, but in P1_G ->
generic
   with package P1 is new P1_G(<>); -- IN THERE
package P2_G is

>The rule is too keep it as simple as possible. If there is any way to ditch generics, do it. Use interfaces and tagged types, mix-ins, class-wide access discriminants etc to achieve polymorphism.
 
Eurg... From the little bit I read (and could understand), you're not very popular about this here... I'll rather follow the majority, besides, I do like the idea of generics. And one can ALWAYS find loopholes and flex a language beyond common sense. Do you expect lawyers to be gods ?

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[J-P. Rosen]

Le 21/01/2018 à 21:15, Mehdi Saada a écrit :
> Thanks Dmitry. I just stumpled against another exemple of your point 1, RM's paragraph 11.2.8:
> An exception_name of a choice shall not denote an exception declared in a generic formal package.
Right, and there is a good reason.
Assuming exception E is declared in generic package GP1:

Imagine this:
generic
   package P1 is new GP1 (<>);
   package P2 is new GP1 (<>);
package GP2 is... end GP2;

package body GP2 is
   ...
begin
   exception
      when P1.E =>  -- not allowed by Ada
         ...
      when P2.E =>  -- not allowed by Ada
         ...
end GP2;

So far, so good. But then, if you instantiate:
package Inst1 is new GP1;

package Inst2 is new GP2 (Inst1, Inst1);

then you would end up with two different handlers for the same exception
(since formals P1 and P2 are actually the same package Inst1). And
that's a no-no!

I agree with Dmitry (It happens sometimes ;-) ) that normally,
exceptions are better declared outside of generics.
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Jeffrey R. Carter]

On 01/21/2018 10:31 PM, Mehdi Saada wrote:
> the exception handler "when P1.Zero_Denominateur => sth;" raises:

Note that you write P1.Zero_Denominateur, not P1_G.Zero_Denominateur. The 
exception is declared in the instance, not in the generic.

> P2_G.Child.adb:66:25: exception "Zero_Denominator" is declared in generic formal package
> P2_G.Child.adb:66:25: and therefore cannot appear in handler (RM 11.2(8))

P1 is a generic formal package.

> generic
>     with package P1 is new P1_G(<>); -- IN THERE

Right, in P1, which is an instance of P1_G.

A generic package is not a package; it's a mechanism for creating packages, 
called instances. A generic package doesn't declare anything; it states what 
instances will declare.

-- 
Jeff Carter
"Saving keystrokes is the job of the text editor,
not the programming language."
Preben Randhol
64

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Mehdi Saada]

I think I already got the idea, and wrote things accordingly... Though a (generic) child of a generic package WILL access through prefixing with his parents'name, not the name of this instance. So in this case things are really declared in the generic package. But I've no problem with that here:

An exception is declared in an package, P1, instance of P1_G, and the RM says I can't use it in a handler... why so ? Renaming doesn't work either. It's stupid, why doesn't it behave like a normal package ! As long as the different instances don't share the same name, there are no reason.
I wrote P1.Exception_Name, not P1_G.Exception_Name, so it should call on the instance. Yet the compiler says "is declared in generic formal package". ??

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Mehdi Saada]

I think I already got the idea, and wrote things accordingly... Though a (generic) child of a generic package WILL access through prefixing wiith his parents'name, not the name of an instance.
 
An exception is declared in an package, P1, instance of P1_G, and the RM says I can't use it in a handler... why so ? Renaming doesn't work either. It's stupid, why doesn't it behave like a normal package ! As long as the different instances don't share the same name, there are no reason.
I wrote P1.Exception_Name, not P1_G.Exception_Name, so it should call on the instance. Yet the compiler says "is declared in generic formal package".

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Dmitry A. Kazakov]

On 22/01/2018 00:07, Mehdi Saada wrote:
> I think I already got the idea, and wrote things accordingly... Though a (generic) child of a generic package WILL access through prefixing with his parents'name, not the name of this instance. So in this case things are really declared in the generic package. But I've no problem with that here:
> 
> An exception is declared in an package, P1, instance of P1_G, and the RM says I can't use it in a handler... why so ?

No, it does not say so. As Jeffrey already explained, generic package is 
not a package. An exception declared in a generic package is not an 
exception until the package is instantiated. You cannot reference to 
that fake exception as a normal one.

    generic
    package P is
       E : exception; -- This is not an exception yet
    end P;

    package True_Thing is new P;

    True_Thing.E -- This is an exception proper

Now consider this:

declare
    package True_Thing_1 is new P;
    package True_Thing_2 is new P;
begin
    ...
exception
    when True_Thing_1.E => -- Catch one E
       ...
    when True_Thing_2.E => -- Catch another E
       ...
end;

The fake exception within P refers to the true exception values from 
both instances, from all possible instances, actually. There are 
situations when that *generic* reference is ambiguous or undefined. This 
is the reason for limitations like the one you encountered.

> Renaming doesn't work either.

Renaming cannot change anything here.

> It's stupid, why doesn't it behave like a normal package !

Because generics are macro expansions, they are not Ada, they are 
meta-language on top of normal Ada ("object language" is the term).

Ada designers did a very tough job making generics act as if they were 
of the object language but there are limits of possible.

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

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Simon Wright]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

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

> On 22/01/2018 00:07, Mehdi Saada wrote:

>> An exception is declared in an package, P1, instance of P1_G, and
>> the RM says I can't use it in a handler... why so ?
>
> No, it does not say so. As Jeffrey already explained, generic package
> is not a package. An exception declared in a generic package is not an
> exception until the package is instantiated. You cannot reference to
> that fake exception as a normal one.

The message we get is

   generics.ada:17:10: exception "Ex0" is declared in generic formal package
   generics.ada:17:10: and therefore cannot appear in handler (RM 11.2(8))

and the AARM reason is "This is because the compiler doesn't know the
identity of such an exception, and thus can't enforce the coverage
rules." Well, if you say so ...


[-- Attachment #2: example --]
[-- Type: text/plain, Size: 334 bytes --]

generic
package G0 is
   Ex0 : exception;
   procedure P0;
end G0;
package body G0 is
   procedure P0 is null;
end G0;
with G0;
generic
   with package G is new G0 (<>);
procedure G1;
procedure G1 is
begin
   G.P0;
exception
   when G.Ex0 => null;
end G1;
with G0;
package R0 is new G0;
with G1;
with R0;
procedure R1 is new G1 (R0);

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Mehdi Saada]

> Imagine this:
> generic
>    package P1 is new GP1 (<>);
>    package P2 is new GP1 (<>);
> package GP2 is... end GP2;

> package Inst1 is new GP1;
> package Inst2 is new GP2 (Inst1, Inst1);
> then you would end up with two different handlers for the same exception (since formals P1 and P2 are actually the same package Inst1). And that's a no-no!

Ah ! Now I get it. Earlier explanations seemed like chinese homonyms, but a fine example makes it crystal clear. The terminology is this area, is still too abstract and confuses me, 'cause I barely touched it yet. I didn't considered that eventuality of two different views (is that the term ?) of the same instances screwing with each others... eventhough it's not so much convoluted.

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Simon Wright]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Right, and there is a good reason.
> Assuming exception E is declared in generic package GP1:
>
> Imagine this:
> generic
>    package P1 is new GP1 (<>);
>    package P2 is new GP1 (<>);
> package GP2 is... end GP2;
>
> package body GP2 is
>    ...
> begin
>    exception
>       when P1.E =>  -- not allowed by Ada
>          ...
>       when P2.E =>  -- not allowed by Ada
>          ...
> end GP2;
>
> So far, so good. But then, if you instantiate:
> package Inst1 is new GP1;
>
> package Inst2 is new GP2 (Inst1, Inst1);
>
> then you would end up with two different handlers for the same
> exception (since formals P1 and P2 are actually the same package
> Inst1). And

This doesn't seem a million miles away from having name clashes caused
by use-visibility.

Agreed, the _instantiation_ must fail.

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Mehdi Saada]

Le lundi 22 janvier 2018 16:36:10 UTC+1, Mehdi Saada a écrit :
> > Imagine this:
> > generic
> >    package P1 is new GP1 (<>);
> >    package P2 is new GP1 (<>);
> > package GP2 is... end GP2;
> package Inst1 is new GP1;
> package Inst2 is new GP2 (Inst1, Inst1);
> then you would end up with two different handlers for the same exception (since formals P1 and P2 are actually the same package Inst1). And that's a no-no!
Ah ! Now I get it. Earlier explanations seemed like chinese homonyms, but a fine example makes it crystal clear. The terminology is this area, is still too abstract and confuses me, 'cause I barely touched it yet. I didn't considered that eventuality of two different views (is that the term ?) of the same instances screwing with each others... eventhough it's not so much convoluted.


... Thinking about it, I was under the false assumption that the generic itself was passed as parameter, and instanciated by or inside the second generic package, whereas it's clear from the instanciation of the latter, that it takes on an INSTANCE. I wasn't even conscious of that confusion. It just messed up my reasoning...

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Randy Brukardt]

"Mehdi Saada" wrote :

>A generic package P1 is formal parameter of an other generic package P2. P2 
>has a
> (public) son. P1 is instanciated in the public part of P2's 
> specifications.

This doesn't make much sense.

A formal package parameter is passed an instantiation as the actual 
parameter. As such, it can't be "instanciated" anywhere, including in P2's 
specification.

The parameter, like the other formal parameters, can be used in children of 
P2.

So I'm not sure what you're asking.

                             Randy.

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p42tst$17l0$1@gioia.aioe.org...
...
> It is a general problem with generics that something legal when compiling 
> it might turn legal or illegal depending on actual formal parameters. In 
> some cases Ada just ignores that, e.g. by treating things wrongly or in an 
> unexpected way, in other cases it tries to prevent that. It is an uphill 
> battle. There is no way to fix generics/templates/macros.

To put this statement into language-lawyer terms, Ada generally uses 
"assume-the-best/assume-the-worst" when it comes to checking Legality Rules 
that depend on actual parameters. In a generic specification, the rules are 
checked "assume-the-best" and are rechecked when the generic is 
instantiated. In a generic body, the rules are checked "assume-the-worst". 
(Which means sometimes you can get rid of an error by moving a declaration 
into the private part of the specification.)

For some rules, "assume-the-worst" would result in not allowing a feature at 
all. In such cases, the rules are checked with a dynamic check instead 
(typically, raising Program_Error if the code would have been illegal if not 
in a generic body).

I'm not aware of any cases remaining where Ada just does the wrong thing, 
but Dmitry is correct that this has been a never-ending battle that tends to 
get repeated every time we invent a new feature.

And of course, that's just the language. Compilers tend to get these rules 
wrong or simply forget to implement them, since they're uncommon. Which 
compounds the annoyances. (ACATS Test submissions are always welcome, 
especially in this area, presuming that there isn't already a test for the 
issue.)

                                Randy.

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:ly8tcp28nv.fsf@pushface.org...
> "J-P. Rosen" <rosen@adalog.fr> writes:
>
>> Right, and there is a good reason.
>> Assuming exception E is declared in generic package GP1:
>>
>> Imagine this:
>> generic
>>    package P1 is new GP1 (<>);
>>    package P2 is new GP1 (<>);
>> package GP2 is... end GP2;
>>
>> package body GP2 is
>>    ...
>> begin
>>    exception
>>       when P1.E =>  -- not allowed by Ada
>>          ...
>>       when P2.E =>  -- not allowed by Ada
>>          ...
>> end GP2;
>>
>> So far, so good. But then, if you instantiate:
>> package Inst1 is new GP1;
>>
>> package Inst2 is new GP2 (Inst1, Inst1);
>>
>> then you would end up with two different handlers for the same
>> exception (since formals P1 and P2 are actually the same package
>> Inst1). And
>
> This doesn't seem a million miles away from having name clashes caused
> by use-visibility.
>
> Agreed, the _instantiation_ must fail.

Ah, but remember the "language-lawyer" message I wrote a few minutes ago. 
Ada enforces Legality Rules in the body in an "assume-the-worst" manner. 
Thus, if any possible instantiation would cause a failure, it is illegal in 
a generic body.

This was done to make the contract model of generics sensible. If one can 
compile a generic body, then the body is always legal for an instantation. 
This allows sane separate compilation, where the body doesn't necessarily 
exist when the instantation is compiled. If the instantiation proves legal 
when compiled, it will stay that way regardless of what is in the body. 
Otherwise, you would have the legality of instantiations changing when a 
body is changed, meaning that you would be getting errors in far off 
compilation units.

Some compilers do in fact do pure macro substitutions, and give the effect 
of proper separate compilation by compiling the instances during binding. 
This is OK and not noticable to a user, because those instances have to be 
legal (modulo compiler bugs, of course). If a compiler worked this way 
without the assume-the-worst rules, you'd get lots of error messages at bind 
time, long after you thought you had a clean compile. That would be annoying 
at best.

                                      Randy.

Re: making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him

[Mehdi Saada]

I really have a hard time with technical terms. To sum up my understanding (excluding use of limited_with), a picture is worth a thousand words. Is that ok ?

with Generic_package_P0; 
with normal_package;
private with private_only;

generic
	with package P1 is new P1_G;
package P2_G is
	package P0 is new Generic_package_P0;[...];
private
	package P0_v2 is new Generic_package_P0; -- private_only visible
end P2_G;

generic
package P2_G.Child is
	-- Generic_package_P0, normal_package, P0 visible
	-- can also instanciate Generic_package_P0, whose instance will be visible below in private and body part. 
private
	-- the same, P0_V2 is also visible P0_v2 and private_only
end P2_G.Child;
package body P2_G.Child
	-- same for instanciating any generic.
	-- exact same than above in private part, plus things declared here and hidden from above as well as for later children.
end body P2_G.Child;