comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: GNAT GPL Edition - on the plus side
Date: Fri, 14 Oct 2005 19:12:40 +0200
Date: 2005-10-14T19:12:28+02:00	[thread overview]
Message-ID: <b4p2ksjzkv4m.6ghazx68f8js.dlg@40tude.net> (raw)
In-Reply-To: c741d$434faf1d$49956a2$22390@ALLTEL.NET

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



  reply	other threads:[~2005-10-14 17:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-14  1:41 GNAT GPL Edition - on the plus side Steve
2005-10-14  4:44 ` randomm
2005-10-14 10:12   ` Alex R. Mosteo
2005-10-14 10:37     ` Martin Dowie
2005-10-19  6:06   ` jussij
2005-10-14  5:55 ` Simon Wright
2005-10-14  8:10 ` Dmitry A. Kazakov
2005-10-14  9:36   ` Martin Dowie
2005-10-14 13:13   ` Marc A. Criley
2005-10-14 17:12     ` Dmitry A. Kazakov [this message]
2005-10-14 19:05       ` Georg Bauhaus
2005-10-15  9:28         ` Dmitry A. Kazakov
2005-10-15  0:00       ` Randy Brukardt
2005-10-15 14:45         ` Robert A Duff
2005-10-15 16:14           ` Dmitry A. Kazakov
2005-10-16  0:48             ` Robert A Duff
2005-10-16  9:56               ` Dmitry A. Kazakov
2005-10-14 13:50   ` Steve
2005-10-14 17:25     ` Dmitry A. Kazakov
2005-10-14 18:58       ` Georg Bauhaus
2005-10-15  9:31         ` Dmitry A. Kazakov
2005-10-15  1:45       ` Steve
2005-10-15 11:18         ` Simon Wright
2005-10-14 17:42   ` Pascal Obry
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox