Dynamic Variant Record Creation
in [ADA]
|
From: Adam Beneschan on 16 Mar 2010 19:24 On Mar 16, 1:31�pm, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > Warren <ve3...(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. Actually, I don't think overload resolution would be an issue, as long as the aggregate (or at least the components that are in variant parts) is specified using named associations. As you said, the information about the components isn't used to determine the expected type of the aggregate. Once the type is determined from context, the names of the variant components would be enough to determine which variants must be present, and therefore what the allowable values of the governing discriminant(s) are. (And, of course, if two component names are specified that cannot exist at the same time, it's already illegal.) However, this wouldn't work if positional notation is used, and this inconsistency (discriminants must be static if components are in positional notation but need not be if they use named associations) would be enough reason for me to say this is a bad idea, if I didn't already think it was, which I do. -- Adam
From: Randy Brukardt on 16 Mar 2010 19:39 "Adam Beneschan" <adam(a)irvine.com> wrote in message news:c3fa9a0f-99c7-4fff-9310-7e4d769065db(a)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=><> in the aggregate (or something >along those lines). I don't know whether it's worthwhile, though. >(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.) I'll consider making a proposal >for this, depending on how loud a groan Randy, Bob, etc., make when >they read this idea... :) GROAAANNN!!! :-) 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 generate, so it would effectively have to generate a giant case statement: X := (Token => T, others => <>) would become: case T is when LEX_ID => X := (Token => LEX_ID, String_Id => <>); when '!' => X := (Token => '!'); ... 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. Randy.
From: Randy Brukardt on 16 Mar 2010 19:43 "Randy Brukardt" <randy(a)rrsoftware.com> wrote in message news:hnp4r7$eqo$1(a)munin.nbi.dk... .... > The compiler could combine similar variants, I guess, but it often doesn't > help much. And it looks like a very complex mess. I didn't mention that there you also could only default initialize most of the components that way. So it's hardly different than writing a default-initialized object with a discriminant constraint (the Georg/Jeff solution). That means that the net gain is unlikely to be enough to be worth the pain. Randy.
From: Robert A Duff on 16 Mar 2010 20:15 "Randy Brukardt" <randy(a)rrsoftware.com> writes: > GROAAANNN!!! :-) ;-) > 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 generate, > so it would effectively have to generate a giant case statement: > > X := (Token => T, others => <>) would become: > > case T is > when LEX_ID => X := (Token => LEX_ID, String_Id => <>); > when '!' => X := (Token => '!'); > ... > end case; Well, this is not hugely different from the case statement that the compiler has to generate for: X : Token_Unit (Token => T); to default-initialize stuff. But I agree it's not worth the trouble. By the way, why do we call the kind/type of token "Token", and the whole token is "Token_Unit" or some such? I realize that's what the compiler textbooks often do, but I'd prefer the enumeration be called Token_Kind, and the record (containing the kind as well as the identifier string or whatever) be called something else, like Token. - Bob
From: Adam Beneschan on 17 Mar 2010 00:20
On Mar 16, 4:39�pm, "Randy Brukardt" <ra...(a)rrsoftware.com> wrote: > "Adam Beneschan" <a...(a)irvine.com> wrote in message > > news:c3fa9a0f-99c7-4fff-9310-7e4d769065db(a)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=><> in the aggregate (or something > >along those lines). �I don't know whether it's worthwhile, though. > >(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.) �I'll consider making a proposal > >for this, depending on how loud a groan Randy, Bob, etc., make when > >they read this idea... �:) > > GROAAANNN!!! �:-) > > 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 generate, > 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 := (Token => T, others => <>) would become: > > case T is > � �when LEX_ID => X := (Token => LEX_ID, String_Id => <>); > � �when '!' => X := (Token => '!'); > � �... > 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. > > � � � � � � � � � � � � � � � � � �Randy. |