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

George Neuner <gneuner2@comcast.net>
Thu, 06 Jan 2011 15:45:23 -0500

          From comp.compilers

Related articles
[23 earlier articles]
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)
Re: language design implications for variant records in a pascal-like jm@bourguet.org (Jean-Marc Bourguet) (2011-01-05)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2011-01-06)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2011-01-06)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2011-01-06)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2011-01-06)
Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2011-01-06)
Re: language design implications for variant records in a pascal-like DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-01-08)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-10)
Re: language design implications for variant records in a pascal-like gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-01-10)
Re: language design implications for variant records in a pascal-like haberg-news@telia.com (Hans Aberg) (2011-01-10)
Re: language design implications for variant records in a pascal-like compilers@is-not-my.name (2011-01-10)
[26 later articles]
| List of all articles for this month |

From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: Thu, 06 Jan 2011 15:45:23 -0500
Organization: A noiseless patient Spider
References: 10-12-040 10-12-052 10-12-064 11-01-008
Keywords: types, design

On Fri, 31 Dec 2010 17:02:23 -0500, noitalmost <noitalmost@cox.net>
wrote:


>For now, I'm not going to include variant records in my language, but I'm
>going to try to keep my options open for later. So I guess I'd like an example
>of where it would be nice to have a variant record. So, assuming our language
>is C++ (so we eliminate cases in C where a union is used only because we don't
>have inheritance), can someone give me a system progamming example that
>requires a union? I'm still looking for that "aha!" moment of its usefulness
>if the language has classes.


The prototypical system programming case is network packet
translation: a packet having an unknown format is read into a buffer
and then various "templates" are overlaid on the buffer to decode the
data.


And yes, this can be done without using variant records, but the
coding is somewhat simpler using them. Because network packet data
contains identifying tags, when using variant records the programmer
doesn't have to manually locate and examine the tags and select a
static record format to overlay.


On the application side, variant records can be useful for FFI
(foreign language functions) and for serialization. Generally, any
kind of tagged data transfer may be fodder for a variant record. It
doesn't matter whether the data is packetized or streamed - in the
stream case you just need to make sure you've got a whole record
before you try to do something with the data.




>Also, is alternation the general term for this type of construct, or is that
>just the way one says union in ML?


"Alternation" is a type theoretic term referring to the set of members
that make up a particular variant case. I use the term "alternation"
preferentially because, depending on the language under discussion,
the terms "variant" and "case" may be overloaded and, without
qualification everywhere, the discussion can quickly become confusing.


ML calls its variant records "algebraic" or "sum" types. In ML the
variant tags are hidden from the programmer and managed by the
compiler. The correct alternation of a sum type is selected by
pattern matching against the (maybe partial) list of field names to be
accessed.


George


Post a followup to this message

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