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

torbenm@diku.dk (Torben Ęgidius Mogensen)
Tue, 04 Jan 2011 12:05:37 +0100

          From comp.compilers

Related articles
[18 earlier articles]
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)
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)
[31 later articles]
| List of all articles for this month |
From: torbenm@diku.dk (Torben Ęgidius Mogensen)
Newsgroups: comp.compilers
Date: Tue, 04 Jan 2011 12:05:37 +0100
Organization: SunSITE.dk - Supporting Open source
References: 10-12-040
Keywords: design, storage
Posted-Date: 04 Jan 2011 11:22:12 EST

noitalmost <noitalmost@cox.net> writes:




> My question is this: Would variant records provide significant value
> to a user of my language (given that classes were implemented)?


You can also reverse the question: Given that you have records and
(tagged) unions (== sum types), will classes provide significant value?


If I had to chose either sum types or classes, my choice will be sum
types -- especially if you have ML-style pattern matching.


For example, syntax trees are much easier to represent using sum types
than using classes.


You can define subtyping without introducing classes:


A record Y is a subtype of a record X if for every field f of type t in
X there is a field f of type t' in Y such that t' is a subtype of t.


A sum type Y is a subtype of a sum type X if for every tag (constructor)
c in Y with type t there is a tag c in X with type t' such that t is a
subtype of t'.


Note the symmetry: Subtypes of a sum have fewer tags and subtypes of a
record have more fields. The empty record can be seen as the top type
in the subtype relation while the empty sum (no possible value) is the
bottom type.


Torben



Post a followup to this message

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