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.1 required=5.0 tests=BAYES_00,PDS_OTHER_BAD_TLD autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,99934eaa35a086e8 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!proxad.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed1.swip.net!swipnet!newsfeed1.funet.fi!newsfeeds.funet.fi!feeder1.news.jippii.net!reader1.news.jippii.net!53ab2750!not-for-mail Message-ID: <420B5D9B.8060400@nowhere.fi> From: Niklas Holsti Organization: Tidorum Ltd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Why should the value for a discriminant be static? References: <420A6FA5.9040802@nowhere.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 10 Feb 2005 15:11:55 +0200 NNTP-Posting-Host: 81.17.205.61 X-Complaints-To: newsmaster@saunalahti.com X-Trace: reader1.news.jippii.net 1108041114 81.17.205.61 (Thu, 10 Feb 2005 15:11:54 EET) NNTP-Posting-Date: Thu, 10 Feb 2005 15:11:54 EET Xref: g2news1.google.com comp.lang.ada:8223 Date: 2005-02-10T15:11:55+02:00 List-Id: Jeffrey Carter wrote: > Niklas Holsti wrote: > >> I agree with the safety advantages of the static rule, but I have >> often wished that an aggregate would allow an expression with a >> statically known subtype as the discriminant *when* this subtype >> uniquely determines the set of components. For example: >> >> type Days is ( >> Monday, Tuesday, Wednesday, Thursday, Friday, >> Saturday, Sunday); >> >> subtype Busy_Days is Days range Monday .. Friday; >> subtype Idle_Days is Days range Saturday .. Sunday; >> >> type Activity (Day : Days) is record >> case Day is >> when Busy_Days => Work : Work_Type; >> when Idle_Days => Play : Play_Type; >> end case; >> end record; >> >> function Do_A_Job (Today : Busy_Days; Job : Work_Type) >> return Activity >> is >> begin >> return ( >> Day => Today, -- Statically known to be in Busy_Days, >> Work => Job); -- therefore this component exists. >> end Do_A_Job; > > > In simple terms, this design if faulty. Now then, that's rather harsh. It's certainly legal Ada; if you think its philosophically faulty, you are entitled to your opinion and I am entitled to disagree; if you think its faulty because it leads to practical problems, the problem is just with the requirement for static discriminants in aggregates -- which is what this thread is about. > It's easy to argue otherwise for > this simple example (7 enumeration values and 2 variants), but I've seen > real world examples where it's harder to argue this way. One had over > 200 enumeration values and about 10 variants. > > I argued in that case that they really needed 11 types: and enumeration > type for the discriminant with about 10 values, and 10 other types, one > for each variant to contain the specific information for the variant. That is of course the work-around. I have done designs both ways depending on the circumstances. > That level of code modification was considered unacceptable, so I > pointed them to the local result variable alternative: > > function F (Day : Busy_Days; Work : Works) > return Activities -- Let's use a consistent naming policy :) (In my own code I consistently use the suffix _T for types.) > is > Result : Activities (Day => Day); > begin -- F > Result.Work := Work; > return Result; > end F; Which loses the compile-check that the assigned components exist and that all existing components are assigned. This is what I (and others) want to avoid. Of course it can be an emergency solution as in your anecdote. The question is one of symmetry: since the language allows static subtypes in the declaration of the variant parts of a record type, it should symmetrically allow statically subtyped expressions as discriminant values in aggregates for such record types. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .