Talk:PL/I

message: Perhaps a link to the current (Jan 2005) PLI newsletter would be useful? 
--ClemMcGann 00:50, 20 Mar 2005 (UTC)
thread_title: PL/I newsletter

message: A large block of text was lost here during a spam/vandalism spree earlier this year. Assuming that this removal was an error, I have added it back, and done some copyediting to remove duplicate material that was added after that piece was lost; I also attempted to organize the material a bit better. Noel (talk) 19:40, 13 Apr 2005 (UTC)
thread_title: Lost text?

message: The first commercial version of the PL/I compiler by IBM was the (F) level compiler. In those days, IBM identified many of its software development/system applications with the letters E, F, G, and H. Each letter specified the minimum S/360 memory configuration needed to run that software. The memory configurations for the different letters were:
           Level E:   32KB
           Level F:   64KB
           Level G:  128KB
           Level H:  256KB        
(Source: IBM System/360 Operating System Introduction Release 21, IBM Publication number GC28-6534-3 avaiable from www.bitsavers.org).
Thus the PL/I (F) level compiler needed a minimum of 44KB to run(Source: IBM System/360 Operating System, PL/I (F) Compiler Program Logic Manual, IBM Publication Number Y18-6800-3, available from www.bitsavers.org).
For comparison purposes, when I run Microsoft's Outlook in Windows XP, it takes up about 14,604KB to sit there waiting for email to come in. This is about 331 times (33,100%) more memory) that the first IBM PL/I compiler.
I also have the code for that first compiler, (available for a small fee to cover cost of media from cbttape.org) and it is most definitely in assembly language. The PL/I (F) compiler is comprised of about 270 source files and about 385,000 lines of IBM assembly language code. This figure does not include code for the libraries, built-in functions, I/O functions and all that.
Now perhaps the PL/I Optimizing Compiler was written in PL/I but I doubt it very much, because the PL/I (F) compiler had a reputation as being a real dog, and one would not use something with that reputation to write an arguably "better" compiler. I used both compilers "back in the day", and there was no way one could shoehorn a compiler of such a massive language as PL/I into 44KB using a high level language.
However, it has been documented that the PL/I "Checkout" compiler WAS written using the PL/I "Optimizing Compiler", the arguably much improved compiler that came after the PL/I (F) level.
The following quote from an article from 1978 summaries the systems that PL/I was used to program:
PL/I, and a variant for systems programming, has been used successfully to program several large operating systems and compilers (notably MULTICS, OS/VS Release 2 Version 2, the PL/I Checkout compiler).
This is from The Early History and Characteristics of PL/I by George Radin, ACM SIGPLAN Notices, 13(8), 1978
RSzoc 18:34, 18 November 2006 (UTC)
thread_title: First commercial compiler

message: Can we insert something about notable/novel features in PL/I, in particular I am curious about AREAS.
NevilleDNZ 21:50, 23 May 2007 (UTC)
replies: text: What's notable or novel about it?  Seems to be similar to FORTRAN COMMON areas, and COBOL Segmentation, both of which preceded PL/I. T-bonham (talk) 05:01, 30 August 2008 (UTC)
replies: text: As I remember it, an area is an unstructured space in which based variables (usually structures) can be allocated. These are referenced through the use of an OFFSET variable defined with respect to the area. The offset is like a pointer, except safer because out-of-bounds errors can be diagnosed at run-time. The offset must always point within the area. I'll have to check my PL/I (F) Reference Guide when I get back to my office.CSProfBill (talk) 17:08, 13 August 2009 (UTC)
thread_title:  PL/I AREAS 

message: Is the semi-colon missing from the PUT SKIP line of the second example intentional? --MarkMLl (talk) 13:49, 25 December 2007 (UTC)
thread_title:  Typo in examples 

message: The 3rd paragraph, "PL/I is considered by some..." was flagged for fact. I edited in a reference that demonstrates that Edsger Dijkstra (at least) made that criticism. That's still not a particularly good reference because it is merely an example of a famous person making the claim, rather than something that states authoritatively that several people made that claim. It's just something that I had just come across and could easily reference. If someone has something better, please fix it again. EMan (talk) 19:21, 5 May 2009 (UTC)
thread_title:  Reference to criticism 

message: As modified, the 3rd paragraph reference does not support the criticism to which it is attached. While I believe the statement is true, it is unsupported by a fact. In denial of the creation and existence of ADA, some people do think PL/I was a turning-point. In the reference (to Dijkstra's Turing Lecture), Dijkstra does lambaste PL/1 for its feature-full nature, but nowhere describes it as a turning-point. Furthermore, in the same article he also says that "Algol 60 is expensive to implement and dangerous to use" and that he sees "a great future for very systematic and very modest programming languages. When I say 'modest' I mean that, for instance, not only AlGOL 60's 'for clause', but even FORTRAN's 'DO loop' may find themselves thrown out as being too baroque." It is rather unfair and non-NPOV to throw such a pot-shot into the introduction of the article.
The trade-off between adding complexity to a language where a documented, common function is available to all and asking each developer to create or find a function implementation for themselves is a complex and contested discussion. Perhaps the view that Guy Steele ("Growing a Language") expresses about growth of language from primitives and embedding features in libraries rather than language represents the proper comprimise. But the point is that if made, such a discussion should be confronted directly, later in the article where it can be presented in full form and not as a rhetorical comment without anything other than an appeal to authority (for which counter-authorities can be found as well). As far as I know there are NO actual studies to illustrate the value trade-offs. The statement should be removed and anyone wishing to discuss the issue in greater depth should please do so - preferably in a context in which it doesn't appear to apply to one programming language among many.
I'm not particularly defending PL/1 - I'm defending the substitution of rationalization for rhetoric when attaching unsubstantiated value judgments.CSProfBill (talk) 18:16, 13 August 2009 (UTC)
thread_title: Criticism of Criticism

message: Can someone add a table of the PL/I datatypes? I remember only a few (BINARY, DECIMAL, FLOAT, CHAR(n), POINTER [BASED], FILE, etc.). — Loadmaster (talk) 21:47, 22 October 2009 (UTC)
replies: text: It would be a big table - about 60 entries ClemMcGann (talk) 22:53, 22 October 2009 (UTC)

text: I've added this, to the level of the Standard. PL/I Optimizer had a few more, e.g Normal/Abnormal, Event and Task.Haven't decided what to do about the Latest IBM PL/I for Z/os - long after my time! RogerofRomsey (talk) 22:20, 21 January 2010 (UTC)
replies: text: Those are attributes. A data type is the combination of attributes that a variable can have, which is (more or less) exponential in the attributes. Numeric variables are either REAL or COMPLEX, either FIXED or FLOAT, either BINARY or DECIMAL, with precision from 1 to some maximum, and for float, with a scale factor from some negative to some positive value. That should leave many thousands of actual data types. Strings can be CHAR or BIT, VARYING or not, and length from 1 to some maximum. Gah4 (talk) 21:53, 13 March 2019 (UTC)
thread_title:  Dataypes 

message: The sections do not relate well to the structure of the articles on PL/I's fellow languages Algol, Cobol, and Fortran. There is excellent debating material, but it does not have the perspective of an Encyclopedia.
I have already rewritten the History section to deal with PL/I's failure to displace Fortran and Cobol and its being overtaken by C for systems work, and the goals section to say that PL/I was bound to be large and complex. I will be removing material from the subject Sections that has been dealt with in History and Goals. Some paragraphs that are significant issues of opinion will be moved to footnotes. Less contentious points will be retained under Implementation Issues, Programmer Issues, Special PL/I Topics.
I introduced a Usage section to hold my material on why PL/I did not displace Cobol and Fortran RogerofRomsey (talk) 15:29, 29 January 2010 (UTC)
thread_title:  Replacing Sections - Retrospective (Design and implementation issues, Programmer preference issues, Improved features), Variables, Storage classes 

message: The "Language Summary " section cites SGML and C++ as Special Purpose languages.  This seems to be not precise enough. SGML is a "language" of sorts - ok, it's part of the name - , but not a Computer Language in the same sense as Algol, Fortran, PL/I, JOVIAL, etc. It's more of a specification. C++ is (really) a general purpose language. I've NEVER heard of it being described as a special purpose language. If special purpose, then what is that special purpose? Other example languages should be chosen as special purpose examples, no? 
RSzoc (talk) 01:53, 18 July 2010 (UTC)
replies: text: Agreed, that sentence is a load of rubbish. I have just removed C++ and tagged it as OR. 205.228.108.58 (talk) 02:56, 20 July 2010 (UTC)
thread_title:  Language Summary and C++ 

message: Currently, though the article has lots of criticism, it has no section called that. Perhaps it got lost at some stage. Cobol and Fortran do have such a section. I am moving the current content - Implementation Issues and Language issues into the section. It will need thinning to reduce it to attributed criticisms, Dijkstra and the like. RogerofRomsey (talk) 17:01, 29 January 2010 (UTC)
thread_title: Criticism Section

message: I have elevated the material to a section and divided it into a subsection per "major" compiler, a subsection on other subsets, and one on dialects. A major compiler is one that had a substantial impact on the development of the language and its general usage; interesting single customer compilers are not major, however interesting.
At this stage I am gathering data and descriptions - platform, year of release or announcement,subset/dialect level. I have added Micro Focus Open PL/I, CDC compilers, PL/I for OS/2, Stratus and Honeywell as Multics derivatives, IBM Series 1 PL/I.
RogerofRomsey (talk) 18:43, 1 February 2010 (UTC)
thread_title: Implementations Section

message: I removed the following inline text by RogerofRomsey from the "'On' block error trapping" section of the article:
:/* Not true. ON-units cannot be terminated by RETURN statements for some good reasons. Would the writer please revise this recently added section. */. 
I also adjusted the text a bit to reflect his point. The section still needs work, though. —  (talk) 18:43, 19 April 2010 (UTC)
replies: text: I never thought about trying, but you should be able to GOTO the return statement of an enclosing procedure. Gah4 (talk) 21:49, 13 March 2019 (UTC)
thread_title:  RETURN from ON-units 

message: I'm putting this here in the talk page because I don't know what else to do with it. It isn't really encyclopedic, but on the other hand isn't any less so than what is in the article under "Usage".
One significant reason that PL/I failed is sheer inefficiency. In particular (and I recognise this is a very very nerdy point) the implementation of the Static Back-Chain Pointer through register 4 in the Optimising Compiler added 14 machine instructions to each procedure call on the off-chance that someone would call a procedure with a another procedure as a parameter - something that no relatively sane person in the commercial world would consider doing even by accident.
In effect (on one program I wrote way back when) this meant a program that in Cobol took two hours to run took 23.5 hours when translated to PL/I (environment specific obviously). So everybody wrote PL/I as if it didn't have procedure calls at all and it might as well have been Cobol.
That seems to me a fundamental design flaw in at least the compiler, if not in the language. And it scares me a bit that after nearly thirty years that register number and the reason for it is still seared on my brain. PL/I might have been a marvellous language (and PL/S was, since it did without this nonsense) but it failed by trying to do everything for everybody and not doing it particularly well for any of us. 
But it is a bit of a moot point whether it was the language design or the implementation that was at fault. Blowed if I can find any reference for this other than my own experience though. Would welcome feedback from others.
Phisheep (talk) 01:56, 1 March 2011 (UTC)
replies: text: I'm skeptical that 14 additional instructions per procedure call could increase run time by 1175%. Did you try compiling with some optimization compiler option, perhaps one that specifically disabled the extra procedure call overhead? In any case, you can't extrapolate one example, or even one implementation, to explain why PL/1 failed to retain its (or grow in) popularity as a programming language. — Loadmaster (talk) 04:07, 1 March 2011 (UTC)
replies: text: A lot of features in PL/I could slow programs down. Dynamic allocation, along with the indirect references needed to use it, is slower than the static allocation of Fortran (at the time).  And yes, some slow downs were due to rarely used features that PL/I allowed for.  While only procedures with the RECURSIVE attribute are allowed to be used recursively, as far as I know, compilers ignore this and generate the same code in both cases. Static save areas used by Fortran result in much faster subroutine linkage than the dynamic save areas of PL/I.  I believe the save area and automatic variables are allocated together, so don't count them separately.  By the time C came along, the extra work for auto variables and recursion weren't so much of a problem, as hardware was faster. Even so, a lot of work is still being done on speeding up procedure calls. (Such as keeping arguments in registers, when possible.) Gah4 (talk) 21:46, 13 March 2019 (UTC)
thread_title:  Why PL/I failed 

message: Recent edits by 74.235.41.177 added links to PHP-based "online compilers" at VintageBigBlue.org. Are these valid links for these WP articles? I tested the COBOL compiler on a simple "Hello, world" program and all it did was return a blank page. — Loadmaster (talk) 20:17, 31 October 2011 (UTC)
thread_title:  Online compiler links 

message: Default attributes for undeclared variables were put into the language for compatibility with FORTRAN, which of course didn't declare most variables.  Should this be added? Peter Flass (talk) 21:32, 3 February 2012 (UTC)
replies: text: Why not? - go ahead - Lugnad (talk) 10:20, 4 February 2012 (UTC)
thread_title:  Implementation issues - undeclared variables 

message: The original change wasn't mine, but I believe FORTRAN is correct:
"All capitals are naturally used in many abbreviated forms such as NATO, FBI, etc.; see Acronyms and initialisms above." Peter Flass (talk) 19:03, 11 March 2012 (UTC)
replies: text: Fortran isn't an acronym. COBOL is. Every letter must stand for something. Most old computer usage was due only to lack of lower-case, and we don't replicate it. Even the current language standard now uses "Fortran" rather than "FORTRAN". Yworo (talk) 19:09, 11 March 2012 (UTC)
replies: text: Fortran was a contraction - FORmula TRANslation - not an acronym, but it was written in uppercase because of convention, not limitation.  At the time, most proper nouns in computing were written in caps, even when publishing mixed-case academic papers about them (which was, after all, the primary discussion mode of the day).  For example, the 1954 Backus et al. report entitled "Specifications for the IBM mathematical FORmula TRANslating system, FORTRAN.".  And since the usage in this case is specifically FORTRAN IV, in support of the "PL/I" name, it probably should be shown in this article as such.  RossPatterson (talk) 19:42, 11 March 2012 (UTC)
replies: text: A good rule of thumb is to see where the Wikipedia article is, it's at Fortran. I removed the comparison as unnecessary. In the Fortran article they choose to make an historical distinction using all-caps for the older versions, Fortran for the newer versions; however, this is explained in the lead of the article. In other articles, we should just use "Fortran", which is the current standard. Yworo (talk) 19:50, 11 March 2012 (UTC)

text: Well, you learn something new every day.  Fortran is indeed an acronym, in the proper, dictionary sense: a word from the first letters of each word in a series of words.  Which doesn't change Yworo's valid point about using the modern "Fortran" form for the language in general.  But references to the 1961 dialect should still be "FORTRAN IV" - even the FORTRAN IV section of the Fortran article reads that way. RossPatterson (talk) 10:41, 13 March 2012 (UTC)
replies: text: Still violates WP:ALLCAPS. Some definitions include this sort of acronym, some definitions don't. It makes since to distinguish in the Fortran article, and it has an explanatory paragraph in the lead, but do you intend to put an explanatory footnote in every other article that uses the all-caps form? Because otherwise knowledgeable editors will probably continue to reduce to normal capitalization. The only reason FORTRAN IV was in all-caps was that computers of the time did not have lower-case at all! Yworo (talk) 19:49, 13 March 2012 (UTC)
thread_title:  FORTRAN vs. Fortran 

message: This section is really not about Object orientation or related features. Should be renamed to something like "Data types". Proposals?  — Preceding unsigned comment added by Towopedia (talk • contribs) 10:47, 29 June 2012 (UTC)
thread_title:  Object orientation 

message: "On the positive side, full support for pointers to all data types (including pointers to structures), recursion, multitasking, string handling, and extensive built-in functions PL/I was indeed quite a leap forward compared to the programming languages of its time. However, these were not enough to convince a majority of programmers or shops to switch to PL/I."
This makes it sound like programmers would want to use these features.  From today's perspective, with most programmers familiar with languages like C and its derivatives, that might seem reasonable.  However, from the perspective of thirty or more years ago, when PL/I was competing with lots of emerging languages (some on the newfangled microcomputers), things like pointers were alien to most COBOL and Fortran (i.e. mainframe) programmers.  Most PL/I I came across then was little different than Fortran in coding style - pointer use was all but forbidden in some shops (I was forbidden to use recursion until the '90s).  The biggest problem I had with most programmers coming onto my PL/I team was getting them to learn and use pointers properly!
Rather than being positive, these things were central to the fear and loathing that most mainframe programmers had for PL/I.  IMHO, of course. 
99.245.248.91 (talk) 19:50, 26 February 2013 (UTC)
replies: text: I disagree, but that's also only my opinion.  Certainly string functions were a big step beyond Fortran's support  for "hollerith" data. Peter Flass (talk) 20:41, 26 February 2013 (UTC)
replies: text: I probably should have taken the last two out of the list.  But pointers, recursion and multitasking were things they didn't want to deal with. 99.245.248.91 (talk) 23:12, 26 February 2013 (UTC)
replies: text: Could be.  Most programmers came to PL/I from a COBOL or FORTRAN background; certainly recursion and multitasking, at least, would have been a stretch for them.  Anyone with an ALGOL background would have "gotten" recursion. I'll have to look at PL/I for FORTRAN Programmers and PL/I for Commercial Programmers to see what they presented, but I think they tried to map FORTRAN and COBOL features to PL/I features, probably leaving out those things you mention. Peter Flass (talk) 00:08, 27 February 2013 (UTC)
thread_title:  Positive?  I'm not so sure 

message: I noticed the citation in the first paragraph ([1], which points to "Sturm, Eberhard (2009). The New PL/I. Vieweg+Teubner. .") doesn't make sense. The paragraph states the language is in active use as of 2011, but the reference was written in 2011. Does anyone with more knowledge about the language have a better reference? Namnatulco (talk) 08:48, 17 March 2013 (UTC)
thread_title:  Citation in first paragraph 

message: Since the switch from Geshi to Pygments for syntax highlighting (phab:T85794), support for PL/I (lang="pli") was unfortunately dropped, as can be seen with the plain text formatting on this page, PL/M, PL/0, IBM i Control Language, SabreTalk, and others such as Do while loop#PL/I , For loop, Record (computer science), Data descriptor, K-mer, Branch table, Stropping (syntax), Gap penalty, Stride of an array, Object composition, Karatsuba algorithm. While_loop, Subroutine and Goto.  If you want PL/I syntax highlight support again, it will need to be added to Pygments. John Vandenberg (chat) 02:19, 12 July 2015 (UTC)
thread_title:  Syntax highlighting 

message: Should the article discuss the name change from PL/1 to PL/I, which as I recall happend during the standardization process?
Wasn't the ANSI standard based on the Vienna Definition Language (VDL) derfinition of PL/I from IBM? Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:50, 28 March 2017 (UTC)
thread_title:  Standardization issues 

message: Is PL/I the first compiled language with array expressions? Gah4 (talk) 02:43, 17 May 2017 (UTC)
thread_title:  Array expressions 

message: Hello fellow Wikipedians,
I have just modified 2 external links on PL/I. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Corrected formatting/usage for http://www-01.ibm.com/software/awdtools/pli
*Added  tag to http://www.kednos.com/
*Added  tag to http://www.bitsavers.org/pdf/ibm/360/pli/C28-6571-1_PL_I_Language_Specifications_Jul65.pdfIBM
*Added  tag to http://www.kednos.com/
*Added archive https://web.archive.org/web/20150721052307/https://vintagebigblue.org/Compilerator/PLIF/dosvsPLICompile.php to https://vintagebigblue.org/Compilerator/PLIF/dosvsPLICompile.php
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 21:50, 1 December 2017 (UTC)
replies: text: The dead ones aren't actually dead, the fixed formatting works, and the added archive doesn't appear to work, probably because it hands stuff to a backend mainframe that isn't there any more. Guy Harris (talk) 23:33, 1 December 2017 (UTC)
thread_title:  External links modified 

message: The claim "It was the first, and possibly the only, programming language standard to be written as a semi-formal definition." seems hard to justify, unless you rule out Algol 68 on the grounds that it was formal rather than semi-formal ;-)  Mhkay (talk) 15:45, 9 September 2018 (UTC)
replies: text: Since PL/I was before 1968, that seems to still qualify as first. The possibly only leaves some wiggle room.  I don't know the ALGOL 68 details at all. As well as I know it, the PL/I language was fairly well defined before the first compiler was written. Was that also true for ALGOL 68?  Were features removed from the (compiler independent) Language Specification later, or just slow in getting implemented?  Gah4 (talk) 21:36, 13 March 2019 (UTC)
replies: text:  At least Lisp, published in 1960, had both syntax and semantics formally specified. Algol had syntax formally specified, semantics semi-formal as far as I know. Does PL/1 had formal semantics specified?  — Preceding unsigned comment added by 201.124.188.198 (talk) 11:02, 10 December 2019 (UTC)
thread_title: Formal Definition

message: I believe that PL/M is more like PL/I, in most ways that matter, than it is to ALGOL, but not enough to qualify as a subset. As they say at the beginning of docudramas, based on a true story (but maybe many important details were changed). I suppose PL/360 could also claim some similarity, but also isn't a subset. Gah4 (talk) 21:32, 13 March 2019 (UTC)
thread_title:  PL/M 

message: Regarding: Performance of compiled code competitive with that of Fortran (but this was not achieved).  Until Fortran 90, Fortran didn't allow recursion. Compilers tended to use static allocation for data, and at least IBM used static allocation for return addresses. PL/I used dynamic allocation for enough things that I don't think you could get away without it on each procedure call. If you were careful with data types and using STATIC variables, you might be close. But then you are competing against the optimization of the Fortran H compiler, which is very good. I doubt that there were enough properly controlled comparisons between them, though. Gah4 (talk) 19:51, 11 February 2020 (UTC)
thread_title:  performance 

message: The article mentions some of the lineage of IBM compilers. I did always wonder about the CALL/OS compiler.  It wasn't all of PL/I (F), but often enough I could used the (F) manual.  Gah4 (talk) 01:47, 25 June 2020 (UTC)
thread_title:  CALL/OS 

message: Should this article be a C class? What improvements are required? I'm not up on procedures enough to look truu the article and see whats missing. Peter Flass (talk) 16:10, 25 February 2021 (UTC)
thread_title:  Assessment 

message: Talk:PL/I#Multics PL/I and derivatives claims  with a citation of , an article that has no connection to either Multics or PL/I, and the claim conflicts with . --Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:07, 30 December 2021 (UTC)
thread_title:  Varying strings in Multics PL/I? 

message: PL/I was adapted as Domain-specific language in SQL context. Main "PLs" today are  PostgreSQL's PL/pgSQL and Oracle's PL/SQL as variations of the SQL/PSM ISO standard. Krauss (talk) 09:53, 9 January 2022 (UTC)
thread_title:  Need content about  PL on SQL domain