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

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

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