Re: language design implications for variant records in a pascal-like language

Robert A Duff <bobduff@shell01.TheWorld.com>
Fri, 31 Dec 2010 08:57:37 -0500

          From comp.compilers

Related articles
[12 earlier articles]
Re: language design implications for variant records in a pascal-like bc@freeuk.com (BartC) (2010-12-29)
Re: language design implications for variant records in a pascal-like DrDiettrich1@aol.com (Hans-Peter Diettrich) (2010-12-29)
Re: language design implications for variant records in a pascal-like marcov@turtle.stack.nl (Marco van de Voort) (2010-12-30)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2010-12-30)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2010-12-30)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2010-12-30)
Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2010-12-31)
Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2010-12-31)
Re: language design implications for variant records in a pascal-like fw@deneb.enyo.de (Florian Weimer) (2010-12-31)
Re: language design implications for variant records in a pascal-like noitalmost@cox.net (noitalmost) (2010-12-31)
Re: language design implications for variant records in a pascal-like gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-01-02)
Re: language design implications for variant records in a pascal-like gene.ressler@gmail.com (Gene) (2011-01-02)
Re: language design implications for variant records in a pascal-like torbenm@diku.dk (2011-01-04)
[37 later articles]
| List of all articles for this month |

From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: Fri, 31 Dec 2010 08:57:37 -0500
Organization: The World Public Access UNIX, Brookline, MA
References: 10-12-040 10-12-052 10-12-057 10-12-065
Keywords: design, storage
Posted-Date: 01 Jan 2011 22:16:28 EST

George Neuner <gneuner2@comcast.net> writes:


> The problem here, I think, is that everyone is fixated on Pascal's
> questionable implementation. IMNHO, Wirth royally screwed up by
> permitting programmer access to the tag field and by requiring the
> programmer to set it correctly ... particularly, in conjunction with
> permitting the new() function to accept alternation tag values and
> return differently sized blocks.


Permitting access to the tag field is not the problem,
nor is using differently sized blocks.
Permitting the tag to be arbitrarily modified is the problem.


> I can't imagine why Ada chose to perpetuate these misfeatures.


I can't imagine that either. ;-)


Ada doesn't perpetuate the misfeatures of Pascal in this area.
In Ada, you can't change the tag fields (called "discriminants")
without filling in all the other fields. For ex:


        type T (Tag: Positive := 1) is
                record
                        case Tag is
                                when 1 | 3 .. 10 =>
                                        This : Boolean;
                                when 2 | 11 .. Positive'Last =>
                                        That : Character;
                        end case;
                end record;


(Note that all Positive values must be covered.
The tag could be of an enumeration type, instead.)


        X : T := (Tag => 1, This => True); -- X.That doesn't exist.
        Y : T := (Tag => 2, That => 'Z');


        X := Y; -- modifies Tag, but also fills in That; This disappears.
        X := (Tag => 10, This => True);


But "X.Tag := ...;" is illegal (at compile time).
So you can't get garbage for This and That, as you
can in Pascal. There's no need for a special "invalid"
tag value.


It is also possible in Ada to allocate just the right amount
of space for the particular variant, in which case you can't
modify the tag at all (not even by the whole-record assignments
as shown above). This works for stack-allocated variables
as well as heap-allocated ones. You can't do that with
C unions, which is an annoying limitation. You can do
it in Pascal, but as you said, it's unsafe, because
the tag field can be set to a wrong value.


If you do a case statement on the tag:


        case X.Tag is
                when 1 | 3 .. 10 =>
                        X.This := not X.This;
                when 2 | 12 .. Positive'Last => -- Illegal -- 11 is missing
                        X.That := 'A';
        end case;


it's illegal (at compile time) if any values are missing,
as above.


> To see good implementations of variant records, take a look at
> alternation (sum) types in the ML family of languages.


Yes, the ML way is better than the Ada way, for most purposes.
One thing you can do in Ada is to control the bit-level
layout, which may be useful in interfacing to hardware
devices and the like.


- Bob


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.