Re: Dynamic Variant Record Creation

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Warren <ve3wwg@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