From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c84654714c2f5945 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!proxad.net!proxad.net!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: GNAT GPL Edition - on the plus side Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1u927xnbmsfw1$.1xg4jk31952ts$.dlg@40tude.net> Date: Fri, 14 Oct 2005 19:12:40 +0200 Message-ID: NNTP-Posting-Date: 14 Oct 2005 19:12:28 MEST NNTP-Posting-Host: ed4fd7f8.newsread4.arcor-online.net X-Trace: DXC=Pl\_?@IYf::j12nnM8XB1>:ejgIfPPld4jW\KbG]kaM8ea\9g\;7Nm5\3\dD8E\3T?[6LHn;2LCV>[ On Fri, 14 Oct 2005 08:13:16 -0500, Marc A. Criley wrote: > Dmitry A. Kazakov wrote: > >> I would do appreciate if they redesigned generics from scratch. Generics >> never worked right in GNAT. It looks much like an architectural problem... >> Maybe then they could finally make generic bodies reusable, error messages >> meaningful, generic specifications compilable etc... > > What the Hell kind of code do you write?? :-) :-) Not a rocket science, I assure you... (:-)) Well, I have posted one trivial example. But it is short, so I believe I can repeat it here: generic type T is digits <>; package A is end A; ----------------------------- with A; generic with package AA is new A (<>); package B is end B; ---------------------------- with B; generic with package BB is new B (<>); package C is X : BB.AA.T; -- So far OK end C; --------------------------- with A; generic with package AA is new A (<>); package E is end E; -------------------------- with B, E; generic with package BB is new B (<>); with package EE is new E (BB.AA); package D is X : BB.AA.T; -- "T" is not a visible entity of "AA" in GNAT GPL end D; The above is successfully compiled by 3.15p, BTW. > I've used GNAT for a long time, and 3.15p almost since the day it was > released, and in all those years have run into only a single handful of > bugs in the compiler--there've been a few in ASIS I've had to work around. I am using it since early 90s. The first case was an Ada 83 program ported from DEC Ada. Guess what? GNAT failed to compile it because on generics! (:-)) > Right now the released version of DTraq is a heavy user of generics, and > there have been no observed ill effects in that area. (The next version > that's under development, though, significantly reduces that use, though > for a totally unrelated redesign reason.) DTraq is over 40 KSLOC, so > it's not a trivial amount of code, plus a few years ago I ported a 90 > KSLOC command and control system to GNAT 3.14, which never encountered > any problems due to compiler bugs. It is not the size of code which causes problems. It is the visibility rules and names of formal and actual parameters, as far as I can tell. It seems that GNAT somehow messes up the names of the actual parameters with ones of the formal parameters upon instantiation. At least some problems can be circumventing by avoiding actual and formal parameter having the same name! (:-)) The example as above is largely a result of Ada's inability to have multiple package parents (*alas!*) and/or specializations (*alas!*). I often need awful: generic with type A ...; with type B ...; with package Foo is new Gen_Foo (A, B); with package Foo1 is new Gen_Foo1 (A, B, Foo); with package Foo2 is new Get_Foo1 (A, B, Foo, Foo1); -- One path with type B ...; with package Bar is new Gen_Bar (B); with package Bar1 is new Get_Bar1 (B, Bar); -- Another path -- etc package Gen_Baz ... To reduce instantiation nightmare with above you could take the actual parameters from other formal parameters: generic with package Foo is new Gen_Foo (<>); package Gen_Foo1 is ... use Foo; -- Got A and B generic with package Foo1 is new Gen_Foo1 (<>); package Gen_Foo2 is ... use Foo1; use Foo; -- Got A and B This is along one path. Alternatively you could use children, but that would have a sufficient drawback: you could not leave the path because the following is illegal: generic with package Foo2 is new Gen_Foo.Gen_Foo1.Gen_Foo2 (<>); package Baz is ... [*why should it be so?!*] Now between the paths there is no other choice than: generic with package Foo2 is new Gen_Foo2 (<>); -- One path with package Bar is new Gen_Bar (Foo2.Foo1.Foo.B); -- Get what it has with package Bar1 is new Gen_Bar1 (Bar); -- Get what it has package Baz ... It is still uncomfortable. But much simpler to maintain. For GNAT it is a great challenge to detect that Foo2.Foo1.Foo.B, Bar.B is actually the *same* type when both packages are use-d in Baz! Add here couple of type "renaming" [done through subtypes] to complete the picture... (:-)) [rant on] Why Ada generics do not have boxes for individual parameters? Why Ada generics do not have specializations? Anyway, generics and templates are inherently a mess, but that is another story. (:-)) [rant off] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de