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: 103376,c469fdacc2f3302b X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!postnews.google.com!k6g2000prg.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Dynamic Variant Record Creation Date: Tue, 16 Mar 2010 21:20:07 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 207.200.116.71 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1268799607 5753 127.0.0.1 (17 Mar 2010 04:20:07 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 17 Mar 2010 04:20:07 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: k6g2000prg.googlegroups.com; posting-host=207.200.116.71; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-Via: HTTP/1.1 (Velocity/1.3.32 [uScMs f p eN:t cCMp s ]), HTTP/1.1 spider-ntc-ta12.proxy.aol.com[CFC8700C] (Prism/1.2.1), HTTP/1.1 cache-ntc-ab07.proxy.aol.com[CFC87447] (Traffic-Server/6.1.5 [uScM]) X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:9623 Date: 2010-03-16T21:20:07-07:00 List-Id: On Mar 16, 4:39=EF=BF=BDpm, "Randy Brukardt" wrote: > "Adam Beneschan" wrote in message > > news:c3fa9a0f-99c7-4fff-9310-7e4d769065db@s25g2000prd.googlegroups.com... > ... > > >By the way, now that Ada 2005 has the <> construct for aggregates, > >it's just occurred to me that maybe 4.3.1(17) can be relaxed a bit, to > >make it legal to specify a record aggregate with a nonstatic > >discriminant for a variant record, *if* the only component > >associations for aggregates are components that are not in variant > >parts *and* there is an others=3D><> in the aggregate (or something > >along those lines). =EF=BF=BDI don't know whether it's worthwhile, thoug= h. > >(It wouldn't help too much in this exact example, since there are no > >non-variant components, but if it were expanded to include, say, a > >source file name, line number, and column number for each Token_Unit, > >then there would be some benefit.) =EF=BF=BDI'll consider making a propo= sal > >for this, depending on how loud a groan Randy, Bob, etc., make when > >they read this idea... =EF=BF=BD:) > > GROAAANNN!!! =EF=BF=BD:-) > > I'd like to see a solution to this problem, but I don't think this is it. > The problem is that the compiler wouldn't know what components to generat= e, > so it would effectively have to generate a giant case statement: My thinking was that it has to do that anyway, if you declare an uninitialized object: Var : Token_Unit(T); This has to use the same sort of case statement to initialize the components in the variant parts. So I thought that basically the code would be using the same logic, plus assigning initial values to the non-variant components. -- Adam > X :=3D (Token =3D> T, others =3D> <>) would become: > > case T is > =EF=BF=BD =EF=BF=BDwhen LEX_ID =3D> X :=3D (Token =3D> LEX_ID, String_Id = =3D> <>); > =EF=BF=BD =EF=BF=BDwhen '!' =3D> X :=3D (Token =3D> '!'); > =EF=BF=BD =EF=BF=BD... > end case; > > The compiler could combine similar variants, I guess, but it often doesn'= t > help much. And it looks like a very complex mess. > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD =EF=BF=BDRandy.