Dynamic Variant Record Creation
in [ADA]
|
From: Warren on 16 Mar 2010 16:59 Robert A Duff expounded in news:wccljdsnh48.fsf(a)shell01.TheWorld.com: > Warren <ve3wwg(a)gmail.com> writes: >>...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. The other way for me to solve this is simply provide a discrimanant that only identifies the few variants. But to keep to 32-bits, I'd have to find a way to specify the discriminant as 3-bits, which I don't think is possible. I'm thinking of bitwise layouts like (random example): for DeviceDetails use record at mod 2; status at 0 range 0 .. 7; rd_stat at 1 range 0 .. 3; wr_stat at 1 range 4 .. 7; end record; except that the discriminant also be described somehow as 3-bits. > I don't see it either. My guess is it involves creating an object > constrained to the right discriminant, without using an > aggregate. I see it now.. yes, same idea. >> 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. No, that won't work because after I have an "identifier", I look it up in keyword (and function name) tables. Once it is recognized as a keyword, LEX_IDENT is replaced with the returned specific keyword id. This simplifies the parser pass later. The character case, is an "others =>" case. Once completed, there will not be many aside from the usual single operators, brackets, comma and colon etc. There's just enough there to be a nuisance. > 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. If true, I'd like to know why. I can't see that in the compiled code being much other than a move short. If I get time tonight, I'll investigate it. > 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. Ya, or I could use a 2005 union perhaps. I'm just trying to keep overhead down and safety "up". This is an experimental rewrite of a C project of mine. Warren
From: Warren on 16 Mar 2010 17:00 Robert A Duff expounded in news:wccpr34nhv2.fsf(a)shell01.TheWorld.com: > 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 Indeed! ;-) Warren
From: Adam Beneschan on 16 Mar 2010 17:15 On Mar 16, 1:31 pm, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > 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. Yes, that was discussed in AC-17. One issue that I don't think was discussed there, however, was that the same discriminant can govern more than one variant part, in the case of nested variants, and then you have issues with discriminated type extensions where an ancestor type may be a discriminant type constrained by the derived type's discriminant. Making sure the rules work in all cases is likely to be a pain. -- Adam
From: Jeffrey R. Carter on 16 Mar 2010 17:55 Warren wrote: > > The other way for me to solve this is simply provide > a discrimanant that only identifies the few variants. But > to keep to 32-bits, I'd have to find a way to specify the > discriminant as 3-bits, which I don't think is possible. Looking at what you have, it looks like a design problem to me. You have a whole bunch of enumeration values, but you don't have a bunch of variants. I'd probably have an enumeration type with 3 values that serves as the discriminant. Then have 3 enumeration types, one for each variant, that gives the specific information that you're now trying to use for the discriminant as well. Whether you can encode that in a certain number of bits as you seem to be trying to do is another question. -- Jeff Carter "Clear? Why, a 4-yr-old child could understand this report. Run out and find me a 4-yr-old child. I can't make head or tail out of it." Duck Soup 94
From: Robert A Duff on 16 Mar 2010 17:58
Warren <ve3wwg(a)gmail.com> writes: > except that the discriminant also be described somehow > as 3-bits. I'm not sure what you mean. If you're saying "I don't know how to specify the layout for discriminants", then the answer is "same as other components" -- you just put the usual "Discrim at ... range 0..2" or whatever. If you're saying "It won't fit in 3 bits because it has more than 2**3 values, then you're out of luck. >> 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. > > If true, I'd like to know why. I can't see that in the compiled > code being much other than a move short. If I get time tonight, > I'll investigate it. Ah, I see I misread your code. I thought you were using 'Image and 'Value. Sorry. So you're right -- the above 'Pos and 'Val should be efficient. But I don't think it does what you want! The 'Pos of the Character '!' is not the same as the 'Pos of the Token '!'. - Bob |