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

George Neuner <gneuner2@comcast.net>
Thu, 23 Dec 2010 17:11:58 -0500

          From comp.compilers

Related articles
language design implications for variant records in a pascal-like lang noitalmost@cox.net (noitalmost) (2010-12-22)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2010-12-23)
Re: language design implications for variant records in a pascal-like danielzazula@gmail.com (Daniel Zazula) (2010-12-24)
Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2010-12-24)
Re: language design implications for variant records in a pascal-like mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2010-12-25)
Re: language design implications for variant records in a pascal-like DrDiettrich1@aol.com (Hans-Peter Diettrich) (2010-12-25)
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)
[58 later articles]
| List of all articles for this month |

From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: Thu, 23 Dec 2010 17:11:58 -0500
Organization: A noiseless patient Spider
References: 10-12-040
Keywords: design, storage
Posted-Date: 25 Dec 2010 16:25:41 EST

On Wed, 22 Dec 2010 15:03:54 -0500, noitalmost <noitalmost@cox.net>
wrote:


>A while back, I created a toy language and compiler with a syntax similar to
>Pascal or Oberon (like what you'd do in an undergrad compiler course). Now I'm
>working on expanding it to a "real" language. I plan eventually to add a class
>type (in the sense of Java or C++ classes), but at present I'm working on
>expanding some of the "procedural language" components, such as a selection
>statement, pointers, floating point type, etc.
>
>My compiler is rather unsophisticated. It's recursive-descent with a scanner
>and parser written "from scratch". It loosely follows Wirth's Oberon0 compiler
>in his Compiler Construction book.
>
>My plan is to have records remain as essentially fixed, compile-time entities,
>so that they can be efficiently compiled. Classes, on the other hand, provide
>polymorphism and the like. The classes are designed to provide more programmer
>flexibility at the price of efficiency.
>
>My question is this: Would variant records provide significant value to a user
>of my language (given that classes were implemented)? My programming
>experience has been that I frequently see unions in C code, but not very often
>in C++ or Java (unless it's specifically to interface with C libraries). So if
>I'm trying to keep my language (and compiler) fairly small, is there a good
>case for variant records, or could everything be handled through classes
>without too much inconvenience to the user programmer?


C++ forbids a union of classes ... so you won't ever see one.


With respect to POD variant record types, I guess they depends on how
you see your language being used. Packed POD records (including
variant types) are very useful for hardware interfacing in a "systems"
language, but in an "application" language the only real attraction of
POD types is that they are (usually) lighter weight and faster than an
equivalent class (though dynamic dispatch can be made O(1) if you are
serious about speed ... unfortunately very few class implementations
are that serious).


Personally, I would say add variant records if it isn't too hard and
won't cause conflict with your intended class implementation. IMO it
never hurts to give the programmer choices.


Wirth eliminated variant records from Oberon, but I think he made some
questionable choices there: he also got rid of enumerations,
subranges, displaced arrays (all array indices start at zero), and
counted loops. Doing so made (small parts of) the compiler simpler,
but made the programmer's job harder ... the wrong way to go IMO.
[Wirth reinstated counted loops in Oberon-2 ... an admission, I think
that he was wrong about leaving them out of Oberon.]


George


Post a followup to this message

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