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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,da85d9aaf769b16a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!news.in2p3.fr!in2p3.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Generic package parameters not externally visible : what's the rational ? Date: Wed, 28 Oct 2009 14:19:58 -0500 Organization: Jacob Sparre Andersen Message-ID: References: <10eygvuzeit9g.xwy2wanxoxgf$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1256757600 21488 69.95.181.76 (28 Oct 2009 19:20:00 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 28 Oct 2009 19:20:00 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Xref: g2news2.google.com comp.lang.ada:8832 Date: 2009-10-28T14:19:58-05:00 List-Id: "Dmitry A. Kazakov" 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. ... >> 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.) Randy.