Re: Intermixing two tagged types

[Adam Beneschan <adambeneschan@gmail.com>]

On Thursday, August 14, 2014 9:11:02 AM UTC-7, Victor Porton wrote:

> Thank you for your suggestion. However I already know this.
> 
> But working this way would be a wrong way. In the meaning of things the 
> entire record is controlled, not its part. So controlling a part would be a 
> hack, not a good way to do programming.

Unfortunately, sometimes you have make compromises to work around the language.

Anyway, if your untagged type has just *one* component that is the "entire" record, that might be close enough to the "right" way to make you feel you're not using a hack--or at least you're using only a minor hack.  If you give the component a one-letter name like R, then it means you have to add "R." every time you want to access a field in your record.  It's a nuisance.  But it might be the least of evils.

I've had to do things like this; usually it's when I have a variant record with a discriminant with a default, like:

    type Value (Value_Type : Value_Classes := Value_Classes'First) is record
        case Value_Classes is
           ...
        end case;
    end record;

(A lot of this was written in the Ada 83 days.)  The rules allow you to change the discriminant of a Value by reassigning the whole record.  But you *can't* do this if you have an "access Value" Acc; you can't change the discriminant of Acc.all by reassigning it.  You *can*, however, wrap Value in another record (with one component V), and if you have an "access Value_Wrapper" Wrapper_Acc, you can change the discriminant of Wrapper_Acc.V.all.  Annoying, but it works.  There were reasons why this rule is in the language, but I wish it had provided a way to let me allocate a "new Value" whose discriminant can be changed.  Providing too many options, however, can muddy the syntax of the language, so it's a trade-off between adding language rules that require annoying workarounds like this, and providing so many features that it drives everybody crazy (language designers, implementors, users) and increases the chance of mistakes or unsafe features creeping into the language semantics.

Bottom line is: there is no Holy Grail of a perfect language, and if you wait for a language that never requires you to do things a "wrong" way, you will be waiting a very, very long time.  We'll probably solve the halting problem  before we can produce a language like that.  :)

                                -- Adam