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

glen herrmannsfeldt <gah@ugcs.caltech.edu>
Sun, 2 Jan 2011 05:57:24 +0000 (UTC)

          From comp.compilers

Related articles
[16 earlier articles]
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2010-12-30)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2010-12-30)
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)
[36 later articles]
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: Sun, 2 Jan 2011 05:57:24 +0000 (UTC)
Organization: A noiseless patient Spider
References: 10-12-040 10-12-043 11-01-005
Keywords: design
Posted-Date: 02 Jan 2011 20:38:30 EST

Robert A Duff <bobduff@shell01.theworld.com> wrote:
(snip)


> 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.
(snip)


> [I have to agree. You want a language with lots and lots of choices,
> look at PL/I. -John]


Part of the design of PL/I was that you wouldn't have to learn all of
it to use it. That was used as the reason for not having reserved
words. (You have to at least know the word to know not to use it.)
Also, the huge list of reserved words for COBOL may have been on the
mind of PL/I designers.


But in many cases PL/I does better than modern Fortran as far as
giving a reasonable number of useful choices.


To keep compatible with older programs, many features from older
versions of Fortran have been kept. PL/I only allows passing arrays
by descriptor, but Fortran has assumed shape (descriptor), and assumed
size (left over, pretty much pass by reference).


-- glen


Post a followup to this message

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