Dynamic Variant Record Creation

Dynamic Variant Record Creation

[Warren]

I am trying to solve a lexer Ada design problem, using a 
variant record (Token_Unit) definition:
        
    type Token_Type is (
        LEX_000,
        LEX_BINARY,
        LEX_SECTION,
        '!',
        '"',
        '#',
        '$', 
        ...etc..
        '^',
        '_',
        '`',
        LEX_SFUN3,
        LEX_SFUN2,
        LEX_SFUN1,
        LEX_SFUNN,
        LEX_FUN3,
        LEX_FUN2,
        LEX_FUN1,
        LEX_FUNN,
        ...etc...
        LEX_EOF
    );

    type Token_Unit(Token : Token_Type := LEX_EOF) is
        record
            case Token is
                when LEX_SFUN3 | LEX_SFUN2 | LEX_SFUN1 | LEX_SFUNN
                   | LEX_FUN3  | LEX_FUN2  | LEX_FUN1  | LEX_FUNN =>
                    Func :      Func_Type;
                when LEX_IDENT | LEX_SIDENT | LEX_LNUMBER | LEX_NUMBER
                   | LEX_HEX   | LEX_STRLIT | LEX_INLREM  | LEX_FLOAT
                   | LEX_REM =>
                    ID :        String_ID;                                                                                                                                                             
                when others =>
                    null;
            end case;
        end record;
                            

    procedure Get_Token(Object : in out Lexer; Token : out Token_Unit) is
                        
        procedure Emit_Token(T : Token_Type) is
            T : Token_Type := Token_Type'Val(Character'Pos(Ch));
        begin
            Token := ( Token => T );
        end;

        ...         
        
    end;

In the above, I need to create a Token_Unit from             
a single character (there is no "id" in this case). The values 
of operator characters are carefully coordinated in the Token_Type 
using a representation clause (just FYI).

But the issue is this:     

*.adb:339:33: value for discriminant "token" must be static
*.adb:339:33: "T" is not static constant or named number (RM 4.9(5))

I could put a huge case statement in, but I'd prefer not to.

Is there a better way to handle the dynamic creation of
a variant record? I have other scenarios involving a    
Func_Type and String_ID as well, which suffer from the same 
"must be static" problem.

I should also mention that I am trying to keep the Token_Unit
to 32-bits, for efficiency.  If it were possible to
divide up the Token_Type (16-bits) into 13-bits and use 
a different descriminant of 3 bits, that would
work also if the total size remained 32. The String_ID 
portion (or Func_Type) are both 16-bit.

Warren

Re: Dynamic Variant Record Creation

[Georg Bauhaus]

Warren schrieb:

>     procedure Get_Token(Object : in out Lexer; Token : out Token_Unit) is
>                         
>         procedure Emit_Token(T : Token_Type) is
>             T : Token_Type := Token_Type'Val(Character'Pos(Ch));
>         begin
>             Token := ( Token => T );
>         end;
> 
>         ...         
>         
>     end;


> In the above, I need to create a Token_Unit from             
> a single character (there is no "id" in this case). The values 
> of operator characters are carefully coordinated in the Token_Type 
> using a representation clause (just FYI).

This text appears to be GNATable:

      procedure Emit_Token(T : Token_Type) is
         Some_T : Token_Type := Token_Type'Val(Character'Pos(Ch));
         subtype Result_Type is Token_Unit (Token => Some_T);
         Result : Result_Type;
      begin
         -- Token := ( Token => T );



         Token := Result;
      end;

> But the issue is this:     
> 
> *.adb:339:33: value for discriminant "token" must be static

Is this true?

Re: Dynamic Variant Record Creation

[Adam Beneschan]

On Mar 16, 10:11 am, Warren <ve3...@gmail.com> wrote:
> I am trying to solve a lexer Ada design problem, using a
> variant record (Token_Unit) definition:
>
>     type Token_Type is (
>         LEX_000,
>         LEX_BINARY,
>         LEX_SECTION,
>         '!',
>         '"',
>         '#',
>         '$',
>         ...etc..
>         '^',
>         '_',
>         '`',
>         LEX_SFUN3,
>         LEX_SFUN2,
>         LEX_SFUN1,
>         LEX_SFUNN,
>         LEX_FUN3,
>         LEX_FUN2,
>         LEX_FUN1,
>         LEX_FUNN,
>         ...etc...
>         LEX_EOF
>     );
>
>     type Token_Unit(Token : Token_Type := LEX_EOF) is
>         record
>             case Token is
>                 when LEX_SFUN3 | LEX_SFUN2 | LEX_SFUN1 | LEX_SFUNN
>                    | LEX_FUN3  | LEX_FUN2  | LEX_FUN1  | LEX_FUNN =>
>                     Func :      Func_Type;
>                 when LEX_IDENT | LEX_SIDENT | LEX_LNUMBER | LEX_NUMBER
>                    | LEX_HEX   | LEX_STRLIT | LEX_INLREM  | LEX_FLOAT
>                    | LEX_REM =>
>                     ID :        String_ID;                                                                                                                                                            
>                 when others =>
>                     null;
>             end case;
>         end record;
>
>     procedure Get_Token(Object : in out Lexer; Token : out Token_Unit) is
>
>         procedure Emit_Token(T : Token_Type) is
>             T : Token_Type := Token_Type'Val(Character'Pos(Ch));
>         begin
>             Token := ( Token => T );
>         end;
>
>         ...        
>
>     end;
>
> In the above, I need to create a Token_Unit from            
> a single character (there is no "id" in this case).

And how is the compiler supposed to know that there is no "id"?

When you use a record aggregate, you need to specify values for every
component of the record.  If the record has a variant part, then the
compiler won't know what components have to be specified unless it
knows what the discriminant is going to be; and it doesn't know what
the discriminants are going to be unless the value of the discriminant
is static.  That's why you get the error you're getting:

> But the issue is this:    
>
> *.adb:339:33: value for discriminant "token" must be static
> *.adb:339:33: "T" is not static constant or named number (RM 4.9(5))

You can't get what you want with an aggregate, but Georg's solution
will give you some of what you want, at least.  However, this will
leave all the components (besides the discriminants) uninitialized,
and you'll need to assign values into them.

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...  :)

                                     -- Adam

Re: Dynamic Variant Record Creation

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3429 bytes --]

Adam Beneschan expounded in
news:c3fa9a0f-99c7-4fff-9310-7e4d769065db@s25g2000prd.googlegroups.com: 

> On Mar 16, 10:11�am, Warren <ve3...@gmail.com> wrote:
>> I am trying to solve a lexer Ada design problem, using a
>> variant record (Token_Unit) definition:
>>
>> � � type Token_Type is (
>> � � � � LEX_000,
>> � � � � LEX_BINARY,
>> � � � � ...etc...
>> � � � � LEX_EOF
>> � � );
>>
>> � � type Token_Unit(Token : Token_Type := LEX_EOF) is
>> � � � � record
...
>> � � � � end record;
>>
>> � � procedure Get_Token(Object : in out Lexer; Token : out Token_Unit
> ) is
>>
>> � � � � procedure Emit_Token(T : Token_Type) is
>> � � � � � � T : Token_Type := Token_Type'Val(Character'Pos(
> Ch));
>> � � � � begin
>> � � � � � � Token := ( Token => T );
>> � � � � end;
>>
>> � � � � ... � � � �
>>
>> � � end;
>>
>> In the above, I need to create a Token_Unit from � � � � � �
>> a single character (there is no "id" in this case).
> 
> And how is the compiler supposed to know that there is no "id"?
> 
> When you use a record aggregate, you need to specify values for every
> component of the record.  If the record has a variant part, then the
> compiler won't know what components have to be specified unless it
> knows what the discriminant is going to be;

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.

The point here is that there is a wide number of discriminant values
that map to the same layout.

Now I don't expect anyone to change the rules in Ada to accomodate
my request. I am simply laying out a "problem" and looking for a
suitable "solution".

>> But the issue is this: � �
>>
>> *.adb:339:33: value for discriminant "token" must be static
>> *.adb:339:33: "T" is not static constant or named number (RM 4.9(5))
> 
> You can't get what you want with an aggregate, but Georg's solution
> will give you some of what you want, at least.  However, this will
> leave all the components (besides the discriminants) uninitialized,
> and you'll need to assign values into them.

I don't currently see "Georg's solution" post, but perhaps it will
arrive soon.

> 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.

As I originally prototyped it, I just shoe-horned it into one 
value with nasty C-like conversions. But I am looking for a cleaner 
"ada way" to do this.

> ...  I'll consider making a proposal
> for this, depending on how loud a groan Randy, Bob, etc., make when
> they read this idea...  :)
> 
>                                      -- Adam

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.

Warren

Re: Dynamic Variant Record Creation

[Jeffrey R. Carter]

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".

-- 
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

Re: Dynamic Variant Record Creation

[Robert A Duff]

Adam Beneschan <adam@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

Re: Dynamic Variant Record Creation

[Warren]

Jeffrey R. Carter expounded in news:hnoosj$a1e$1@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

Re: Dynamic Variant Record Creation

[Robert A Duff]

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

Re: Dynamic Variant Record Creation

[Robert A Duff]

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

Re: Dynamic Variant Record Creation

[Warren]

Robert A Duff expounded in news:wcchbogngp7.fsf@shell01.TheWorld.com:

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

Re: Dynamic Variant Record Creation

[Warren]

Robert A Duff expounded in news:wccljdsnh48.fsf@shell01.TheWorld.com:

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

Re: Dynamic Variant Record Creation

[Warren]

Robert A Duff expounded in news:wccpr34nhv2.fsf@shell01.TheWorld.com:

> Adam Beneschan <adam@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

Re: Dynamic Variant Record Creation

[Adam Beneschan]

On Mar 16, 1:31 pm, Robert A Duff <bobd...@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

Re: Dynamic Variant Record Creation

[Jeffrey R. Carter]

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

Re: Dynamic Variant Record Creation

[Robert A Duff]

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

Re: Dynamic Variant Record Creation

[Adam Beneschan]

On Mar 16, 1:31�pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Warren <ve3...@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

Re: Dynamic Variant Record Creation

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:c3fa9a0f-99c7-4fff-9310-7e4d769065db@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.

Re: Dynamic Variant Record Creation

[Randy Brukardt]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:hnp4r7$eqo$1@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.
 

Re: Dynamic Variant Record Creation

[Robert A Duff]

"Randy Brukardt" <randy@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

Re: Dynamic Variant Record Creation

[Adam Beneschan]

On Mar 16, 4:39�pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Adam Beneschan" <a...@irvine.com> wrote in message
>
> news:c3fa9a0f-99c7-4fff-9310-7e4d769065db@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.

Re: Dynamic Variant Record Creation

[Charmed Snark]

Robert A Duff expounded in news:wcceijk0vze.fsf@shell01.TheWorld.com:

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

Yep, that was what I was after. So it _is_ possible after
all ;-)  I'll keep that in my back pocket for now, because 
I got things working satisfactory now. My cases where I 
had auxiliary info were not that numerous, so I just created
a couple of factory functions employing case statements. Wordy,
but it works.

The "Georg" solution was good for that "catch all case" where
there was no aux info involved.

>>> 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.

Yep, it is (from objdump):

   6:   c6 45 fd 01             movb   $0x1,-0x3(%ebp)
   a:   66 c7 45 fe 01 00       movw   $0x1,-0x2(%ebp)

> 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

Oh yes it does, hee hee. My awk script goes to great lengths 
to define the Token_Type to align with the characters (it 
generates the type specification from #defines, sorted and 
munged from the yacc output y.tab.h). I did alude to this 
in the first post as a FYI, that it has a for Token_Type 
use (...) statement to ensure this. Otherwise, you would
be quite correct.

Thanks to everyone, the problem is now solved and I can 
move on. The Georg solution was key.

Warren

Re: Dynamic Variant Record Creation

[Warren]

Robert A Duff expounded in news:wccr5nj247r.fsf@shell01.TheWorld.com:

>     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

Actually, that is a good point. Before I left the Ada faith a few
years ago, I started doing that (using *_Kind).  Its not too late
for me to make that change, so it might get done tonight. ;-)

Warren

Re: Dynamic Variant Record Creation

[Warren]

Jeffrey R. Carter expounded in news:hnov3m$t4o$1@tornado.tornevall.net:

> 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. 

Yep.

> 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. 

I was considering that. In fact, I am still mulling over that
possibility for the reason that the choice of "aux info" may change
over time. For example a LEX_FLOAT may initially just point (by ID)
back the collected string. Later it may convert to the actual binary
value etc. So having an independed "representation" descriminant, 
may be the right way to go.

> Whether you can encode that in a certain number of bits as you seem to
> be trying to do is another question.

Apparently, that can be done.

Warren

Re: Dynamic Variant Record Creation

[Robert A Duff]

Charmed Snark <snark@cogeco.ca> writes:

> Robert A Duff expounded in news:wcceijk0vze.fsf@shell01.TheWorld.com:
>> 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 '!'.
>
> Oh yes it does, hee hee. My awk script goes to great lengths 
> to define the Token_Type to align with the characters (it 
> generates the type specification from #defines, sorted and 
> munged from the yacc output y.tab.h). I did alude to this 
> in the first post as a FYI, that it has a for Token_Type 
> use (...) statement to ensure this.

But "for Token_Type use (...)" has no effect on the 'Pos/'Val
attributes.  It sets the internal representations, not the
position numbers.

- Bob

Re: Dynamic Variant Record Creation

[Warren]

Robert A Duff expounded in news:wcchbof2ec4.fsf@shell01.TheWorld.com:

> Charmed Snark <snark@cogeco.ca> writes:
> 
>> Robert A Duff expounded in news:wcceijk0vze.fsf@shell01.TheWorld.com:
>>> 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 '!'.
>>
>> Oh yes it does, hee hee. My awk script goes to great lengths 
>> to define the Token_Type to align with the characters (it 
>> generates the type specification from #defines, sorted and 
>> munged from the yacc output y.tab.h). I did alude to this 
>> in the first post as a FYI, that it has a for Token_Type 
>> use (...) statement to ensure this.
> 
> But "for Token_Type use (...)" has no effect on the 'Pos/'Val
> attributes.  It sets the internal representations, not the
> position numbers.
> 
> - Bob

True, but Character'Pos(NUL) is still zero etc. I could get
into trouble though if I were to skip (in Token_Type) any
ranges of [printable] characters, but this is not the case. 
After the last non-printable character, this is unimportant
because I don't apply those.  

Up until the first printable character, I fill in values, 
where I don't have actual token values. Values like LEX_009 
for example. So it does work in this particular case.

Warren

Re: Dynamic Variant Record Creation

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccr5nj247r.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
>> 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.

Well, for Janus/Ada at least, that giant case statement is generated exactly 
once, in the unit containing the type, to create an initialization "thunk". 
We don't keep enough information to do it efficiently later.

Note that the example given is exactly the same as default initialization, 
so that wouldn't be a problem, but if there are additional components 
specified, the default initializer couldn't be used. (It would be incorrect 
to call functions used by the default initial values of components that have 
explicit values. The ACATS [mostly the Ada 83 version] checks for stuff like 
that.)

                            Randy.

Re: Dynamic Variant Record Creation

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:a4de16f2-1b14-4c9d-886a-2e61f6c01863@k6g2000prg.googlegroups.com...
On Mar 16, 4:39?pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
...
>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.

As noted to Bob, that doesn't work in Janus/Ada. There also is a critical 
limitation on our intermediate code: there cannot be case statement-like 
control structures in expressions (we completely separate control flow and 
values in the intermediate code; there cannot be live values when there is 
control flow and vice-versa; values have very limited control flow 
possibilities from short circuit operations and loop initializers).

If the idea offered much additional expressiveness, I wouldn't object, but 
it doesn't seem to have enough.

Steve Baird and I had worked out a partially constrained discriminant 
constraint which would have provided a much better solution to this problem 
along with many others -- but Tucker Taft couldn't seem to wrap his mind 
around the idea (it seemed natural to me) and thus it got quickly killed. 
Thus I don't think there will be any relief.


                                           Randy.

P.S. It probably isn't fair to single out Tucker for killing the idea, but 
since he usually has a much more flexible view of the world, it was bizarre 
that he couldn't understand it. I suspect many took that as an indication 
that it was fatally flawed; I suspect the problem more was one of 
presentation.

Re: Dynamic Variant Record Creation

[Warren]

Jeffrey R. Carter expounded in news:hnov3m$t4o$1@tornado.tornevall.net:

> 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. 

I looked at this closely last night and ended up agreeing
with you (design problem). So I changed it along the 
lines that you suggested:

type Token_Type(Aux : Aux_Kind := No_Aux) is    
    record
        Token :             Token_Kind := No_Token;
        case Aux is
            when SID_Aux =>
                SID :       String_ID;
            when FID_Aux =>
                FID :       Func_ID;
            when No_Aux =>
                null;
        end case;
    end record;

I was also able to get the representation I wanted (yeah):

for Token_Type use
    record
        Aux     at 0    range 0..2;
        Token   at 0    range 3..15;
        SID     at 0    range 16..31;
        FID     at 0    range 16..31;
    end record;

This design allows me to flexible in the auxiliary
information provided. For example, each "token line"
ends with a linefeed token (LEX_LF). However, each
statement has an optional "inline" comment like:

01000 LET OPEN_FLAG = FALSE    $ Mark file as not-opened.

Using the discriminant Aux allowed me to use a SID 
(Aux = SID_Aux) or not ( Aux = No_Aux ) as required:

T := ( Aux => SID_Aux, Token => LEX_LF, SID => ID );

  or

T := ( Aux = No_Aux, Token => LEX_LF );

As you pointed out, when designed this way, I always 
know the static representation required, even though 
the Token member may be variable.

I knew that we'd eventually converge on a solution. 
Thanks everyone.

Warren

Re: Dynamic Variant Record Creation

[Warren]

Randy Brukardt expounded in news:hnrr6j$d7n$1@munin.nbi.dk:

..
> If the idea offered much additional expressiveness, I wouldn't object,
> but it doesn't seem to have enough.
> 
> Steve Baird and I had worked out a partially constrained discriminant 
> constraint which would have provided a much better solution to this
> problem along with many others -- but Tucker Taft couldn't seem to
> wrap his mind around the idea (it seemed natural to me) and thus it
> got quickly killed. Thus I don't think there will be any relief.
> 
>                                            Randy.

As it turned out (in my case at least), the problem was more
of a design problem (see upstream post). Once I reworked the
design, the problem vanished. ;-)

Warren