Re: Generic package parameters not externally visible : what's the rational ?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 28 Oct 2009 14:19:58 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:10eygvuzeit9g.xwy2wanxoxgf$.dlg@40tude.net...
>> On Tue, 27 Oct 2009 16:08:09 -0500, Randy Brukardt wrote:
> ...
>>> I'm not sure that it "makes perfect sense" for them to be visible: it would
>>> surely increase the chance of name collisions outside of the package.
>>
>> Sorry, but that is a "generic" property of anything declared in a generic
>> package. Two instances of the same generic packages always collide when
>> "use"-ed.
> 
> No, I was thinking of name collisions when the formal and actual have the 
> same name (that is very common for subprogram parameters and is not uncommon 
> in generic as well). If the formal is also visible, you end up with two 
> things with the same name. Something like:
> 
>    generic
>        type Int is range <>;
>    package Gen is
>        ...
>    end Gen;
> 
>    with Gen;
>    package Test is
>        type Int is range ...;
>        package My_Gen is new Gen (Int);
>    end Test;
> 
>    with Test;
>    procedure Check is
>       use Test, Test.Gen;
>       Obj : Int; -- (1)
>    ...
> 
> (1) is legal by the current rules, but if the formal was visible, it would 
> become illegal because there would be two Int's visible. That would become 
> worse if any of the proposals for integrated instantiations are adopted, 
> because both Ints would be visible in the same scope, and thus use Test 
> would become ineffective: exactly the reverse of what is wanted from an 
> integrated instantiation.

It is clear that some code will become illegal. Here is another example of
a collision upon instantiation in the current version of Ada:

   generic
      type I is (<>);
   package P is
      type T is tagged null record;
      procedure Foo (Obj : T; X : I);
      procedure Foo (Obj : T; X : Integer);
   end P;

   package Bar is new P (Integer); -- Boom!

I don't think we should much care about backward compatibility with regard
to generics.

My take is that any generic code is potentially broken. Anyone who uses
generics beyond very trivial cases should know that, and mentally prepare
himself to fix his code over and over again.

>>> That's clear from the
>>> syntax (they're outside the package). You're going to say that discriminants
>>> are outside of the type, too, but they're also visible. I can't argue with
>>> that beyond saying that that placement of discriminants is just awful; I
>>> place them in the wrong place and continually forget to include them in
>>> aggregates because they're well away from the other components.
>>
>> That depends on the mental model of the discriminant. If the discriminant
>> is a type constraint, then you are right. But in Ada this concept, if ever
>> existed, has been eroded. Presently discriminant is merely an immutable
>> component. I am also in favor the "constraint" model, and yes, in this
>> model it would be reasonable to make discriminants invisible, e.g. when
>> they are used for construction and then dropped. But that is not the Ada
>> model now.
> 
> ...other than for Unchecked_Unions, and even there the model is incomplete. 
> (You can reference the discriminant in a context where it can be determined, 
> such as for a constrained object, even though it is not stored anywhere. But 
> you can't reference it if the object is unconstrained.)

Yes, I also thought about Unchecked_Unions. It would be great to have
checked Unchecked_Unions without "case" (:-))

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