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

George Neuner <gneuner2@comcast.net>
Thu, 30 Dec 2010 17:57:05 -0500

          From comp.compilers

Related articles
[11 earlier articles]
Re: language design implications for variant records in a pascal-like mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2010-12-29)
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)
[38 later articles]
| List of all articles for this month |

From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: Thu, 30 Dec 2010 17:57:05 -0500
Organization: A noiseless patient Spider
References: 10-12-040 10-12-052 10-12-057
Keywords: storage, design
Posted-Date: 30 Dec 2010 23:02:40 EST

On Wed, 29 Dec 2010 11:42:08 -0000, "BartC" <bc@freeuk.com> wrote:


>"noitalmost" <noitalmost@cox.net> wrote in message
>>
>> I suppose I have an initial prejudice against variant records. They
>> seem to me to be a potential source of hard to find bugs (for the
>> user programmer, I mean, not the compiler designer). Am I wrong
>> about this? Is it possible for the compiler to always know which
>> type is active in the variant, like say through a hidden
>> compiler-generated variable in the record?
>
>I thought the variant record also stored a tag field so that it is possible
>to determine, at run time, exactly which fields are valid in the variant
>part (although I can't remember exactly how this would be used in a
>language; perhaps assign to the tag first, then write the appropriate
>variant field which would then need to be runtime checked)).


The tags can be compiler generated and invisible to the programmer. A
safe implementation would have one or more tag values that mean the
record data is not valid. Assuming the tag field itself can be
atomically updated, a "safe" update would be


    - set the tag field to "invalid"
    - update the fields of the selected subrecord
    - set the tag field to indicate which subrecord is valid


[I know this would be invalid in Pascal, Ada, etc. ... see below.]




>This means the compiler wouldn't know what was going on in the record;


In general, it only means the compiler may not always know (but then
again, it might). Obviously, programmer alternation code may be buggy
or even deliberately lie to the compiler, however, the alternation may
be resolved by compiler generated code (which won't lie and is much
less likely to be buggy).


Just as in OO dispatch, variant records can be resolved at function
(or in general any scope) boundaries and the compiler then can know
the correct alternation to use within that scope and further down the
call chain.




>it would just have the headache of generating code to check the correct
>read and write accesses are being done. (And I understand these variant
>fields can be nested, an even bigger headache, if it's necessary to verify an
>arbitrary path through a tree for any field access!)


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.


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


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




George


Post a followup to this message

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