Related articles |
---|
[4 earlier articles] |
Re: Is multi-level function return possible? anton@mips.complang.tuwien.ac.at (2014-03-16) |
Re: Is multi-level function return possible? news@cuboid.co.uk (Andy Walker) (2014-03-16) |
Re: Is multi-level function return possible? yaldnif.w@blueyonder.co.uk (Bill Findlay) (2014-03-17) |
Re: Is multi-level function return possible? anton@mips.complang.tuwien.ac.at (2014-03-18) |
Re: Is multi-level function return possible? news@cuboid.co.uk (Andy Walker) (2014-03-21) |
Re: Is multi-level function return possible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-03-21) |
Re: exception catching in PL/I, was Is multi-level function return pos robin51@dodo.com.au (Robin Vowels) (2014-03-27) |
From: | "Robin Vowels" <robin51@dodo.com.au> |
Newsgroups: | comp.compilers |
Date: | Thu, 27 Mar 2014 21:08:39 +1100 |
Organization: | Compilers Central |
References: | 14-03-020 14-03-022 14-03-025 14-03-030 14-03-044 14-03-046 14-03-047 14-03-048 14-03-053 14-03-054 |
Keywords: | PL/I, errors, history, comment |
Posted-Date: | 27 Mar 2014 14:58:33 EDT |
From: "glen herrmannsfeldt" <gah@ugcs.caltech.edu>
> The first language I knew with this feature is PL/I.
>
> As well as I understand it, the language was pretty well defined
> before anyone tried writing a compiler for it. They didn't ask many
> users,
The design committee organised by IBM had representatives from business, etc.
The language was to be an improved version of FORTRAN.
By the time that the PL/I language was to be designed, it was patently
evident what was wrong with existing languages. Many years of users'
experience had already been obtained with FORTRAN, and COBOL and ALGOL
had been around nearly as long.
In the end, good features of ALGOL, FORTRAN and COBOL were merged into
the PL/I language.
> though attracting new users would have been important. Seems
> to me they didn't ask so much what was easy to parse (among other
> features, no reserved words)
They continued the idea of FORTRAN, which did not have reserved words.
The bane of COBOL was (and still is) reserved words; ALGOL had a kind
of reserved word in the form of basic symbols, sometimes underlined,
sometimes in apostrophes, depending on the implementation; and thus
the thought that there would be no reserved words in PL/I was a very
attractive one -- and one which, in the end, proved to be the best
choice.
The basic idea of the new language was that it should be easy to use,
easy to write programs, and not to be encumbered by the numerous
exceptions that existed in FORTRAN
> and, at least the way it looks, rarely
> considered how hard it might be to generate code for, or generate
> efficient code for.
>
> Many languages were defined at the same time as the first compiler
> was written, with that compiler defining the language.
Usually there was a plan, before commencing writing, because writing a
compiler was a large task. Undoing parts of the design and redefining
it on the fly would have been expensive in terms of man-hours.
Thus, once the PL/I language was defined, the implementing team set about
writing the compiler.
> [PL/I was, as I understand it, defined largely by glomming together
> parts of Fortran and Cobol with some bits of Algol60. They assumed it
> would be possible to implement since all of the pieces were, although
> there turned out to be a lot of dark corners where things that seemed
> reasonable individually weren't so reasonable in combination. -John]
In the case of the FORTRAN components that were incorporated in PL/I,
most of these were considerably enhanced. The first was the
incorporation of generic built-in functions that would do away with
the need for the user having to cite by individual names functions of
different precisions (such as SIN, DSIN, etc), which would have become
unmanageable with the addition of decimal built-in functions. The
second was a very improved FORMAT statement (or specification),
whereby repeat factors, field widths, and numbers of decimal digits,
could be specified (if required) by expressions in place of immutable
constants as was the case in FORTRAN. The third was the
implementation of proper character handling (hands up those who recall
Hollerith constants?)
In the case of the ALGOL components incorporated into PL/I, the
obvious one was block structuring and dynamic arrays -- something that
significantly constrained users of FORTRAN. Free form for source
statements also is an obvious steal.
Commercial facilities (particularly the data types) were modelled on those in COBOL.
Not all in PL/I was copied from other languages.
One, I regard as one of the important innovations introduced in
PL/I was the ability to trap and handle (recover from) errors,
particularly data conversion errors, but especially subscript and
substring errors. Many man-hours and machine hours were wasted in
trying to track down obscure errors in FORTRAN that could otherwise be
detected instantly they occurred in PL/I, and supported with
information printed out (such as values of variables; the line number
where the error occurred, and where called from).
Other facilities included list-processing and a preprocessor.
[In that last bit I think you're confusing languages and
implementation. WATFOR was checking for subscript and undefined data
errors on the 7040 by 1965. Nothing new there. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.