* making a son benefit access ton an instanciation of a generic package required as a formal parameter to his father and instanciated by him @ 2018-01-21 15:43 Mehdi Saada 2018-01-21 15:58 ` Simon Wright 2018-01-23 1:13 ` Randy Brukardt 0 siblings, 2 replies; 22+ messages in thread From: Mehdi Saada @ 2018-01-21 15:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 15:43 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 @ 2018-01-21 15:58 ` Simon Wright 2018-01-21 17:30 ` Mehdi Saada 2018-01-23 14:05 ` Mehdi Saada 2018-01-23 1:13 ` Randy Brukardt 1 sibling, 2 replies; 22+ messages in thread From: Simon Wright @ 2018-01-21 15:58 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 15:58 ` Simon Wright @ 2018-01-21 17:30 ` Mehdi Saada 2018-01-21 17:39 ` Simon Wright 2018-01-21 17:50 ` Dmitry A. Kazakov 2018-01-23 14:05 ` Mehdi Saada 1 sibling, 2 replies; 22+ messages in thread From: Mehdi Saada @ 2018-01-21 17:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 17:30 ` Mehdi Saada @ 2018-01-21 17:39 ` Simon Wright 2018-01-21 17:50 ` Dmitry A. Kazakov 1 sibling, 0 replies; 22+ messages in thread From: Simon Wright @ 2018-01-21 17:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 17:30 ` Mehdi Saada 2018-01-21 17:39 ` Simon Wright @ 2018-01-21 17:50 ` Dmitry A. Kazakov 2018-01-21 20:15 ` Mehdi Saada 1 sibling, 1 reply; 22+ messages in thread From: Dmitry A. Kazakov @ 2018-01-21 17:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 17:50 ` Dmitry A. Kazakov @ 2018-01-21 20:15 ` Mehdi Saada 2018-01-21 20:41 ` Dmitry A. Kazakov 2018-01-21 22:04 ` J-P. Rosen 0 siblings, 2 replies; 22+ messages in thread From: Mehdi Saada @ 2018-01-21 20:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 20:15 ` Mehdi Saada @ 2018-01-21 20:41 ` Dmitry A. Kazakov 2018-01-21 21:29 ` Mehdi Saada 2018-01-23 1:23 ` Randy Brukardt 2018-01-21 22:04 ` J-P. Rosen 1 sibling, 2 replies; 22+ messages in thread From: Dmitry A. Kazakov @ 2018-01-21 20:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 20:41 ` Dmitry A. Kazakov @ 2018-01-21 21:29 ` Mehdi Saada 2018-01-21 21:31 ` Mehdi Saada 2018-01-23 1:23 ` Randy Brukardt 1 sibling, 1 reply; 22+ messages in thread From: Mehdi Saada @ 2018-01-21 21:29 UTC (permalink / raw) > 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 ? ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 21:29 ` Mehdi Saada @ 2018-01-21 21:31 ` Mehdi Saada 2018-01-21 22:20 ` Jeffrey R. Carter 0 siblings, 1 reply; 22+ messages in thread From: Mehdi Saada @ 2018-01-21 21:31 UTC (permalink / raw) > 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 ? ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 21:31 ` Mehdi Saada @ 2018-01-21 22:20 ` Jeffrey R. Carter 2018-01-21 23:07 ` Mehdi Saada 0 siblings, 1 reply; 22+ messages in thread From: Jeffrey R. Carter @ 2018-01-21 22:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 22:20 ` Jeffrey R. Carter @ 2018-01-21 23:07 ` Mehdi Saada 2018-01-21 23:10 ` Mehdi Saada 2018-01-22 8:28 ` Dmitry A. Kazakov 0 siblings, 2 replies; 22+ messages in thread From: Mehdi Saada @ 2018-01-21 23:07 UTC (permalink / raw) 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". ?? ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 23:07 ` Mehdi Saada @ 2018-01-21 23:10 ` Mehdi Saada 2018-01-22 8:28 ` Dmitry A. Kazakov 1 sibling, 0 replies; 22+ messages in thread From: Mehdi Saada @ 2018-01-21 23:10 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 23:07 ` Mehdi Saada 2018-01-21 23:10 ` Mehdi Saada @ 2018-01-22 8:28 ` Dmitry A. Kazakov 2018-01-22 9:25 ` Simon Wright 1 sibling, 1 reply; 22+ messages in thread From: Dmitry A. Kazakov @ 2018-01-22 8:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-22 8:28 ` Dmitry A. Kazakov @ 2018-01-22 9:25 ` Simon Wright 0 siblings, 0 replies; 22+ messages in thread From: Simon Wright @ 2018-01-22 9:25 UTC (permalink / raw) [-- 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); ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 20:41 ` Dmitry A. Kazakov 2018-01-21 21:29 ` Mehdi Saada @ 2018-01-23 1:23 ` Randy Brukardt 1 sibling, 0 replies; 22+ messages in thread From: Randy Brukardt @ 2018-01-23 1:23 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 20:15 ` Mehdi Saada 2018-01-21 20:41 ` Dmitry A. Kazakov @ 2018-01-21 22:04 ` J-P. Rosen 2018-01-22 15:36 ` Mehdi Saada 2018-01-22 15:52 ` Simon Wright 1 sibling, 2 replies; 22+ messages in thread From: J-P. Rosen @ 2018-01-21 22:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 22:04 ` J-P. Rosen @ 2018-01-22 15:36 ` Mehdi Saada 2018-01-22 15:54 ` Mehdi Saada 2018-01-22 15:52 ` Simon Wright 1 sibling, 1 reply; 22+ messages in thread From: Mehdi Saada @ 2018-01-22 15:36 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-22 15:36 ` Mehdi Saada @ 2018-01-22 15:54 ` Mehdi Saada 0 siblings, 0 replies; 22+ messages in thread From: Mehdi Saada @ 2018-01-22 15:54 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 22:04 ` J-P. Rosen 2018-01-22 15:36 ` Mehdi Saada @ 2018-01-22 15:52 ` Simon Wright 2018-01-23 1:33 ` Randy Brukardt 1 sibling, 1 reply; 22+ messages in thread From: Simon Wright @ 2018-01-22 15:52 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-22 15:52 ` Simon Wright @ 2018-01-23 1:33 ` Randy Brukardt 0 siblings, 0 replies; 22+ messages in thread From: Randy Brukardt @ 2018-01-23 1:33 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 15:58 ` Simon Wright 2018-01-21 17:30 ` Mehdi Saada @ 2018-01-23 14:05 ` Mehdi Saada 1 sibling, 0 replies; 22+ messages in thread From: Mehdi Saada @ 2018-01-23 14:05 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 22+ messages in thread
* 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 2018-01-21 15:43 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 2018-01-21 15:58 ` Simon Wright @ 2018-01-23 1:13 ` Randy Brukardt 1 sibling, 0 replies; 22+ messages in thread From: Randy Brukardt @ 2018-01-23 1:13 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2018-01-23 14:05 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-21 15:43 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 2018-01-21 15:58 ` Simon Wright 2018-01-21 17:30 ` Mehdi Saada 2018-01-21 17:39 ` Simon Wright 2018-01-21 17:50 ` Dmitry A. Kazakov 2018-01-21 20:15 ` Mehdi Saada 2018-01-21 20:41 ` Dmitry A. Kazakov 2018-01-21 21:29 ` Mehdi Saada 2018-01-21 21:31 ` Mehdi Saada 2018-01-21 22:20 ` Jeffrey R. Carter 2018-01-21 23:07 ` Mehdi Saada 2018-01-21 23:10 ` Mehdi Saada 2018-01-22 8:28 ` Dmitry A. Kazakov 2018-01-22 9:25 ` Simon Wright 2018-01-23 1:23 ` Randy Brukardt 2018-01-21 22:04 ` J-P. Rosen 2018-01-22 15:36 ` Mehdi Saada 2018-01-22 15:54 ` Mehdi Saada 2018-01-22 15:52 ` Simon Wright 2018-01-23 1:33 ` Randy Brukardt 2018-01-23 14:05 ` Mehdi Saada 2018-01-23 1:13 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox