Dynamic Variant Record Creation
in [ADA]
|
From: Robert A Duff on 16 Mar 2010 16:15 Adam Beneschan <adam(a)irvine.com> writes: >...I'll consider making a proposal > for this, depending on how loud a groan Randy, Bob, etc., make when > they read this idea... :) As an implementer, I groan. ;-) As a user, not so much. - Bob
From: Warren on 16 Mar 2010 16:24 Jeffrey R. Carter expounded in news:hnoosj$a1e$1(a)tornado.tornevall.net: > Warren wrote: >>>> procedure Emit_Token(T : Token_Type) is >>>> T : Token_Type := Token_Type'Val(Character'Pos( >>> Ch)); >>>> begin >>>> Token := ( Token => T ); >>>> end; > > I missed a bunch of this thread. But you can do what you want: > > declare > Result : Token_Unit (Token => T); > begin > Token := Result; > end; > > Quite possibly this is also "Georg's solution". I haven't had a chance to see if this "works", but the compiler seems a little happier now- but warns: *.adb:327:13: warning: variable "Result" is read but never assigned Perhaps a dummy assignment after I am through with it would be enough. Is there a better way of dealing with the warning? I'll give this a go later tonight, when I have more time. Warren
From: Robert A Duff on 16 Mar 2010 16:31 Warren <ve3wwg(a)gmail.com> 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
From: Robert A Duff on 16 Mar 2010 16:40 Warren <ve3wwg(a)gmail.com> writes: > *.adb:327:13: warning: variable "Result" is read but never assigned > > Perhaps a dummy assignment after I am through with it > would be enough. Is there a better way of dealing with > the warning? When a warning is a false alarm, I think the appropriate way to deal with it is to use pragma Warnings. There's a rich variety of features to suppress warnings on a fine-grained or coarse-grained basis. See the docs. But first make sure you really believe it is a false alarm, and then put in a comment explaining why. (Sounds like in this case, it's OK because you have no components besides the discriminant). Contorting the code (e.g. inserting a dummy assignment) is rarely the way to go. Neither is it a good idea to simply ignore them -- you should be able to have a clean (warning-free) build. In fact, I'd go so far as to say a compiler that gives warnings (some of which are false alarms) is broken if it doesn't support some way to suppress them. Warning: pragma Warnings is GNAT specific. But that's OK; it won't harm portability. - Bob
From: Warren on 16 Mar 2010 16:44
Robert A Duff expounded in news:wcchbogngp7.fsf(a)shell01.TheWorld.com: > Warren <ve3wwg(a)gmail.com> writes: >> *.adb:327:13: warning: variable "Result" is read but never assigned >> Perhaps a dummy assignment after I am through with it >> would be enough. Is there a better way of dealing with >> the warning? > > When a warning is a false alarm, I think the appropriate way to > deal with it is to use pragma Warnings. I'll dig that up tonight. > But first make sure you really believe it is a false alarm, > and then put in a comment explaining why. (Sounds like > in this case, it's OK because you have no components > besides the discriminant). Yep, in this specific case, anyway. > Contorting the code (e.g. inserting a dummy assignment) is > rarely the way to go. Neither is it a good idea to simply > ignore them -- you should be able to have a clean (warning-free) > build. Agreed. > Warning: pragma Warnings is GNAT specific. But that's OK; > it won't harm portability. > > - Bob That's ok-- the project is skewed to gnat anyway. Thanks, Warren |