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

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

          From comp.compilers

Related articles
[6 earlier articles]
Re: language design implications for variant records in a pascal-like gene.ressler@gmail.com (Gene) (2010-12-27)
Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2010-12-27)
Re: language design implications for variant records in a pascal-like noitalmost@cox.net (noitalmost) (2010-12-27)
Re: language design implications for variant records in a pascal-like cr88192@hotmail.com (BGB) (2010-12-27)
Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2010-12-28)
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)
[43 later articles]
| List of all articles for this month |
From: "BartC" <bc@freeuk.com>
Newsgroups: comp.compilers
Date: Wed, 29 Dec 2010 11:42:08 -0000
Organization: A noiseless patient Spider
References: 10-12-040 10-12-052
Keywords: storage, design
Posted-Date: 29 Dec 2010 09:34:40 EST

"noitalmost" <noitalmost@cox.net> wrote in message
> Thanks all for your replies. They've been helpful.
>
> Tentatively, I'm calling my language Wipl (for Wirth Inspired Programming
> Language).


> Supposing Wipl, Oberon, and Ada to lie in the same "nanny language"
> category, Wipl sits much closer to Oberon than to Ada, though I
> think Oberon somewhat of a minimalist extreme.


> As for the use of Wipl, I would like to keep it in the "general
> purpose" category, mainly for applications, but also poentially for
> OS development. I was hoping one day to translate minix or (a
> subset of) linux to Wipl. This goal is what got me thinking about
> variant records.


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


This means the compiler wouldn't know what was going on in the record; 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!)


In the case of a C union, no tag is stored; it's up to the programmer to
keep track of what shared field is currently active. But C is a low level
language and unions are one of the features it needs to support that aim.
And compiler support for unions can be minimal.


(In my own designs, I use neither variant fields nor unions. I use instead
field aliases:


    record r (
        int a, b
        real x @ a
        int c
    )


so here x (64 bits) shares the same offset as a, and the same space as a and
b (32 bits each).


But this is also intended for nefarious purposes, and is an untidy feature
of a higher level language, with it's own problems (how many fields are in
this record?). However compiler support is straightforward: x is simply
assigned offset 0 instead of 8.)


So, my feeling would be to leave them out, provided you have enough other
features to make your OS work practical.


--
Bartc


Post a followup to this message

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