Re: PL/I string representations

From: robin (robin_v_at_bigpond.mapson.com)
Date: 12/31/03 

Date: Wed, 31 Dec 2003 14:46:15 GMT

From: Randy Howard <randy.howard@FOOmegapathdslBAR.net>, Imperious Overlords Anonymous
Date: Mon, 29 Dec 2003 05:15:29 -0600

> Well, this may not be a definitive source, but it does have several
> chapters devoted to PL/I. The book is "Introduction to Programming
> Languages", by W. Wesley Peterson, Prentice-Hall, 1974.
>
> I apologize in advance to the expert PL/I programmers if this is all
> redundant, there have been several here who claim little or no knowledge
> of the language, so it was interesting to me, hopefully it will be to
> those individuals as well. If you care not, now would be a good time to
> bail.
>
> There are multiple chapters in the text on PL/I, but since we are
> concerned with EGN's claim that PL/1 originally used a byte to store
> string length, thus limiting strings to 255 characters, I focused on
> Chapter 8, dedicated to string processing with PL/I.
.
There is nothing in the PL/I language that limits the length of a
string to any particular value.
.
Nor, for that matter, is there anything to limit the size of
an array.
.
The actual limits are the prerogative of the manufacturer.
.
> The book also covers BASIC, FORTRAN, ALGOL, APL, COBOL, SNOBOL, LISP,
> as well as appendices on "Revised Report on the Algorithmic Language
> ALGOL60", "Computer Programming Problems", "Typical Computer Runs",
> "Implementation of Recursive Procedures" and "Language Processor
> Availability".
>
> In the latter, Appendix F, page 351, he writes "PL/I -- all programs
> except the last program in Chapter 4 were run on the IBM PL/I Optimizing
> Compiler. The last program in Chapter 4, and many others, were run with
> the IBM F-level compiler, and except for minor restrictions on the use
> of pointers and the requirement in some cases for ENTRY declarations, I
> believe all will run with the F-level compiler."
>
> I also note that he used IBM compilers for the FORTRAN, ALGOL60, APL,
> and COBOL sections, along with Bell Labs SNOBOL4, Illinois Institute
> of Technology SPITBOL, Waterloo LISP and "UHBASIC, information available
> from the author". The reason I mention this is that the author makes
> the claim in the first paragraph of the first chapter on PL/I that
>
> "It appears now that PL/I will become the most important
> programming language in the next decade."
>
> The heavy dependency on IBM compilers may simply imply that IBM was
> marketing PL/I heavily as "the next big thing at the time", however an
> jargon file reference describes the famous dmr quote "you know where
> to find it" was based upon defending C against PL/I.
>
> The author probably was not aware of C (or have any idea of its future
> wide use) at this time as it was just getting started during the period
> of time in which this book was being written. Similarly BCPL and B are
> not mentioned at all.
>
> In October of 1963, a committee formed within SHARE, the organization
> of users of large IBM computers, to specify a program with the
> goals of satisfying scientific, commercial, real-time and systems
> programmers. Also NPL (New Programming Language) was an early name
> for PL/I. The original expectation was that the new language would
> be an extension of FORTRAN, but the committee took a broader view.
.
You can't make a silk purse out of a sow's ear.
.
> The first IBM manual on PL/I appeared in 1965, and the result was
> a language bearing a close resemblance to ALGOL,
.
The best parts of Algol, FORTRAN, and COBOL, and were taken
and improved on to become the features of PL/I.
In respect of Algol, the only resemblances were in the block
structure and in the existence of recursion.
I/O was modelled on COBOL and FORTRAN.
Interrupt handling was new.
.
> but much broader
> in scope and more closely oriented to real computers (particularly
> the IBM 360/370) than ALGOL.
.
Algol gained popularity as a publication language and as a programming
language, but its main lack was the initial absence
of any standard I/O (which was generally clumsily implemented)
and to the problems that arose on hardware.
.
> A contemporary of the author, a "Professor Saul Rosen" (university
> unspecified) flamed the IBM/SHARE community for creating a new language
> as a "crash project" completed by only six men, "some of which had other
> responsibilities at the same time" (THE HORROR!!) which was believed to
> be important to the entire computing community at the time. A source for
> this "flame" was a review in "Computing Reviews VI No. 2 (1965).
> Apparently politics and complaining about language standards committees
> is not a new thing after all. :-)
>
> The author of this book goes on to say that the result of this
> "rush job" was a lot of special cases, exceptions, and inattention
> to the little details that made the language difficult to cleanup,
.
which langage? FORTRAN?
.
> except by defining a new language.
.
The only way forward was to define a new language.
It took 25+ more years to evolve FORTRAN to the stage
where it resembled a modern programming language (Fortran 90),
but it still lacks basic features that were available in
PL/I in 1966.
.
> He goes on to say that this
> caused manufacturers of other computers (than IBM) to be very
> reluctant to produce PL/I compilers. If you're curious how
> the "most important language of the decade" could have this
> flaw,
what is that?
> we think similarly. However, he explains this away as the
> growing popularity of PL/I amongst the IBM community forced
> other manufacturers to produce compilers to remain competitive.
>
> String declarations in PL/I look like the following:
>
> DECLARE A CHARACTER(5) INITIAL ('ALICE');
> DECLARE B CHARACTER(5);
> DECLARE C CHARACTER(10) INITIAL ('YAMAMOTO');
>
> The author points out that they always have the exact length
> specified, so that the string representation of "C" will
> actually be 'YAMAMOTO ' with two blanks inserted to make
> it's length ten.
>
> Additionally, variant length strings can be specified with
> DECLARE E CHARACTER(20) VARYING;
>
> The specified length is the minimum, and each time a character
                              ~~~~~~~~
Actually, the specified length is the maximum.
.
> string is assigned to E, the length is stored with it. There
> is a built in function LENGTH that gives the length of
> character strings.
>
> Concatenation is done as follows:
>
> E = A||C;
>
> results in the value 'ALICE YAMAMOTO '. He doesn't explain the
> space between the two, it may be automatically inserted, or a
> typo. I do not know for sure.
.
An error. There would be no space in this instance.
.
> There is also a "beautiful" TRANSLATE(S,T,U) function. T and U must
> be character strings of identical length, every occurrence in S of
> the first character in U is replaced by the first character in T,
> etc. For example:
>
> TRANSLATE(S,'GAR','BEL')
>
> will replace every 'B' in S by 'G', every 'E' by 'A' and every
> 'L' by 'R'.
>
> If the third argument is omitted entirely, then all possible bytes
> (256) in the string in order of their binary code is assumed to
> be present. A sort of "auto template" to make wholesale
> translations easier. Keep in mind this is all based on the 256
> character EBCDIC character set.
.
It is based on whatever character set is available.
The PL/I language never specified what internal code should be used.
At that time (1966), almost every manufacturer had a different
internal representation for characters - a situation that
persisted into the 1980s.
.
> I also found out that it was actually possible to use language
> keywords as variable names and the parser would figure out what
> you meant from context. EGN was claiming that C has design flaws?
> Yeah, right.
.
Having keywords that are not reserved words means that should
the language be extended at some future time, it will
not prevent old programs from compiling successfully.
.
It also means that it is unnecessary to commit to memory
all of the reserved words. It would otherwise be possible
to inadvertently use an obscure keyword as a variable.
Programmers don't go out of their way to use keywords as
identifiers.
.
> If you are wondering where the punch line is with respect to the
> maximum string length or the internal representation of a
> string, unfortunately the author did not mention it at all. Either
> it was an omission, or it was not a problem. To be fair, this
> book was written almost ten years after the language came about,
> so the problem might have been gone by this time.
.
The maximum length was sufficiently high so as not to be a problem -
32767 characters for the IBM F compiler, c. 1966.
.
IBM's "PL/I Reference Manual" (2nd edition, March 1968 C28-8201-1) p. 34
specifies a limit of 32767 characters.
   As the limit of 32767 was not flagged as a change from the first
edition, it can be taken that the limit of 32767 was in
existence in the first edition.
   Furthermore, the 2nd edition applied to the 4th version of the
PL/I F compiler, and therefore the limit of 32767 characters applied
at least to the 3rd version of the F compiler.
.
> Attempts at finding a reference to this string limitation in
> early PL/I compilers via google was unsuccessful, however many
> of the links which came up where dead and gone. IBM still
> offers compilers for their big iron though, but I did not find
> any reference to this on their pages either.
>
> In the course of other investigation, I discovered that PL/I was
> developed at IBM's Hursley Park research facility in England.
.
That was IBM's PLI F compiler. The D compiler was developed
elsewhere, possibly Germany.
.
Other manufacturers developed their compilers independently.
.
> Maybe Richard has a better chance to bulldog this one. :-)
>
> Some IBM docs on a windows PL/I compiler are here:
> http://www-306.ibm.com/software/awdtools/pli/pliwin/library/
>
> I did find this at a link off the above:
> "The storage allocated for VARYING strings is 2 bytes longer than the
> declared length. The leftmost 2 bytes hold the string's current length"
.
That gives a maximum of 32767 characters for current IBM PL/I for
Windows and other workstation products and for the current
IBM Enterprise PL/I for the mainframe machines.
.
> There is also apparently a VARYINGZ in the language now that uses
> C-style \x00 terminated strings to avoid arbitrary limits.
.
The C-style does not avoid arbitrary limits.
Such a string cannot contain the character 00x as
this would terminate it prematurely.
.
> I found no reference to this in the earlier book.
>
> --
> Randy Howard