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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,4ce5890331a5b529 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news1.google.com!news3.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.68.MISMATCH!feeder.news-service.com!94.75.214.39.MISMATCH!aioe.org!not-for-mail From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= Newsgroups: comp.lang.ada Subject: Re: Discriminants of tagged types Date: Wed, 27 Oct 2010 17:58:06 +0200 Organization: Ada @ Home Message-ID: References: <14314714-e92c-4036-9cbb-da8e72489261@h7g2000yqn.googlegroups.com> NNTP-Posting-Host: si1wcqmfPAlDmjwCD+0L/g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 User-Agent: Opera Mail/10.63 (Win32) Xref: g2news1.google.com comp.lang.ada:14842 Date: 2010-10-27T17:58:06+02:00 List-Id: Indeed, this show very well how can default discriminants be a mess (and= = there are other reasons too to add to the ones given here). A question then come : do someone know something to which default = discriminants are unavoidable ? I feel default discriminants can simply = be = dropped (kind of sugar?), but I would like to be sure. The OP asked about the rationale behind the choice to disallow default = discriminant values in some case. May be to ask about the rationale behi= nd = the decision to introduce default discriminant values would be worth too= . Le Wed, 27 Oct 2010 17:06:24 +0200, Adam Beneschan a = =C3=A9crit: > AARM 3.7(9.d): "Defaults for discriminants of tagged types are > disallowed so that every object of a tagged type is constrained, > either by an explicit constraint, or by its initial discriminant > values. This substantially simplifies the semantic rules and the > implementation of inherited dispatching operations. For generic formal= > types, the restriction simplifies the type matching rules. If one > simply wants a 'default' value for the discriminants, a constrained > subtype can be declared for future use." > > One issue with untagged types with default discriminants is that if > you define a type like that: > > type Rec (Discr : Integer :=3D 0) is record ... > > and declare a procedure with an IN OUT parameter of that > (unconstrained) type: > > procedure Proc (R : in out Rec) is > begin > ... > R :=3D (Discr =3D> R.Discr + 1, [other components =3D> ...]) > -- whether this is allowed depends on the actual parameter > end Proc; > > you could declare both an unconstrained and constrained object of that= > type and pass them both to Proc: > > R1 : Rec; > R2 : Rec(10); > > Proc (R1); > Proc (R2); > > Proc is allowed to assign a new value to R that changes the > discriminant, but it has to know that if R2 is the actual parameter, > the discriminant is not allowed to change. This requires additional > information to be passed to Proc so that it knows whether to raise > Constraint_Error when the assignment to R happens. Apparently it was > felt that where tagged types, class-wide types, and dispatching were > involved, this would make things too complicated. > > This may seem "annoying" to those who think that a default > discriminant is *just* a default (rather than creating a different > kind of type that allows the creation of both constrained and > unconstrained objects). But the last sentence of the AARM note shows > that the workaround is simple enough. (Personally, I would have > preferred that the two concepts not be mixed, and that there be two > syntaxes---one for specifying a default value for discriminants, and > another to specify that unconstrained objects of the type can be > created. It's not the only case where having one syntax do "double > duty" ends up causing problems. I think AI05-154 is a symptom of > this, in which putting a constraint on a nominal array subtype not > only specifies a constraint but also tells the compiler that an > 'Access can't be used as an access-to-unconstrained-array value, > causing headaches when you want to include a constraint but *also* > want the ability to have an access-to-unconstrained-array point to the= > object; another case, perhaps, where "double duty" may have seemed > like a clever solution to avoid extra syntax, but turned out not to be= > such a good idea.... But I'm starting to rant a bit.) > > -- Adam -- = Si les chats miaulent et font autant de vocalises bizarres, c=E2=80=99es= t pas pour = les chiens.