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

On Fri, 31 Dec 2010 09:05:40 -0500, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:


Rearranged a bit for continuity:


>George Neuner <gneuner2@comcast.net> writes:
>
>> 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.
>
>I rather strongly disagree with that last sentence. Giving the
>programmer more choices means the programmer has more to learn,
>and the compiler writer has more work to do. That's a good
>idea only if the alternatives are sufficiently useful.
>
>- Bob
>[I have to agree. You want a language with lots and lots of choices,
>look at PL/I. -John]


Why do so many languages offer (at least) two forms of conditional
loop: one with the test at the beginning and another with the test at
the end? Why not just offer an infinite loop and a way to break out
that can be tied to any conditional?


You're absolutely right that a language doesn't need 10 ways to
accomplish the same thing ... I fully agree that having too many
equivalent choices is needless waste. But apparently redundant
features can be justified by programmer convenience as well as for
unique uses.




>In this case, I don't think it's worth it -- I think it's possible
>to design a single language feature that does everything classes
>can do, and everything variant records can do. No need for
>two completely different features, each with its own syntax
>and semantics.


What classes can do depends on your frame of reference. Most OO
languages have object implementations that are quite limited in
expressiveness.


In any event, I agree that it's possible to provide a single feature
that has both POD and polymorphic behavior using the same syntax. In
fact it has already been done.


When OO was new, some early Pascal implementations had no distinct
class type but rather offered extended record types (including
variants) which permitted "member" functions/procedures to be
logically attached to the type and called using the field selection
operator: e.g., "x = rec.func()". Sans user defined pointer fields,
these extended records still were POD types so they could be used
either as records or as objects.


George

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