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,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!xmission!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Dynamic Variant Record Creation Date: Tue, 16 Mar 2010 16:31:19 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1268771465 749 192.74.137.71 (16 Mar 2010 20:31:05 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 16 Mar 2010 20:31:05 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:7wKOwk23LIN594hpeATUzio/aY0= Xref: g2news1.google.com comp.lang.ada:9607 Date: 2010-03-16T16:31:19-04:00 List-Id: Warren writes: > Of course. But it is not conceptually inconceivable to > check this at runtime and realize that the value I handed > out will work with what was provided. If not, then > raise an exception. Not inconceivable, I suppose, but that would be a huge language change. It would require totally rethinking the overload resolution rules, because currently there's a fundamental principle that the type of an aggregate is determined by context (ignoring the components), and once that type is known, the component expressions are resolved knowing their types. I really don't think you want to do overload resolution at run time. On the other hand, I can imagine some rule based on subtypes, where you don't know the discriminant statically, but you know statically that it's in a particular subtype that all shares the same variant. > The point here is that there is a wide number of discriminant values > that map to the same layout. Right, but you'd need to come up with a rule that can determine which one it is, statically. Otherwise, the sky would fall. > Now I don't expect anyone to change the rules in Ada to accomodate > my request. Probably not in this case, but it's fun to discuss language changes even if we know they're not going to happen. >...I am simply laying out a "problem" and looking for a > suitable "solution". Sure. It's a real problem. I've run into it myself. > I don't currently see "Georg's solution" post, but perhaps it will > arrive soon. I don't see it either. My guess is it involves creating an object constrained to the right discriminant, without using an aggregate. > I wasn't looking for compiler-implementation/language amendments. > Just looking for good advice on how others would takle this problem. > Perhaps the full case statement is the right way, but I gotta say > that it puts a damper on readability. One solution is to write the aggregates out at each place. That is, when the lexer decides it needs to create '!' token, it uses an aggregate ('!', ...) rather than passing '!' to Emit_Token. I guess that's what you mean by the "case statement" way. You said you wanted efficiency. Well, this: T : Token_Type := Token_Type'Val(Character'Pos(Ch)); is unlikely to be efficient. The case statement will be better in that regard. Another solution is to make the record non-variant. Store Func and Id in the same component, and use whatever conversions you need. Wrap this in accessor functions. You can do the variant checks by hand in the accessor functions -- that is Get_Func(Tok) would check that Tok.Token in the right set. The lexer would see the full type, it's client (a parser, I assume) would use the accessor functions. - Bob