![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
The inappropriate link to Talk:PL above is because of a technical restriction.
I deleted the following, which is not true:
IBM mainframes used separate symbols for the letter and the number. The 'I' in PL/I is a roman numeral. -- Simon J Kissane
I was trying to make a distinction between the character and the font. Unfortunately, I used the wrong symbols. It was the small "L" and the number "1" that used to identical font symbol (i.e., l and 1 look the same - more or less - even though I typed the "el" character first, and the "one" character second).
I was not intending to say that the characters were identical (i.e., had identical values in EBCDIC), merely that they looked the same. This was true for the Courier font ball used in IBM Selectrics, which were also used as operator terminals in some S/360 installations, and the font symbols may have been identical in the print cylinder in the 1403 printer. Because I don't have the original context - or don't know how to get my original contribution for the context, I'm not sure why I even brought up the character confusion thing... Cheers --17:29, 31 December 2006 (UTC) RSzoc
The bit about SABRE is from personal experience. I was offered (and turned down) a position with the SABRE project ca 1965. Don't know if they stayed w/ PL/I or changed to a different language.
The (military/aerospace) project I was on at the time would have used PL/I if it had been useable early enough. We went through major contortions to do a real-time/multi-tasking system requiring dynamic allocation of records (structs to you C weenies) in FORTRAN IV. Further, FORTRAN required 512K of RAM to compile, the PL/I compiler would work in 128K. -- Buz Cory
Evidently, the SABRE folks didn't get a really solid PL/I compiler for their platform until the early 1970s. They may have wanted to use PL/I earlier than that, but I can vouch that at least the portions of the system that American Airlines dealt with were almost entirely 7090 assembler before the early 1970s. (Working off my father's notes on this one; he wrote the compiler, so there's a chance his history is biased, of course.) -- Cliff Biffle
Not so sure about that "case insensitive" part. At that time virtually all work was done entirely in upper case due to hardware limitations. -- Buz Cory
Nice job on the history. Some references to written documents (which I understand may not exist) would be nice. If its personal experience, then say so. -- drj
Most of the history stuff I added is purely from memory. I read it somewhere. I wasn't even alive when PL/I was being developed. -- Simon J Kissane
A couple of inaccuracies in the "Retrospective section".
First, it states that the "user wouldn't know whether a statement was a declaration or a executable statement until one saw the period at the end. " The truth is that PL/I uses (and has always used) the semi-colon as a statement terminator. COBOL is that language that used periods. Additionally, a declaration statement ALWAYS begins with the keyword "DECLARE" or "DCL", so it's easy to figure out what kind of statement it is. Also, "format free" languages that could be spread along a number of lines before being terminated had been around since at least the early 1960/61 if not earlier. Even assembly language could span multiple lines if one put a "continuation" character in Column 72 of the "card".
Second, the article states that "the decision to make spaces unimportant, as in Fortran" (I paraphrase) is simply not true. In Fortran, spaces were truly irrelevant. Thus, one could write an "do statement" as follows:
DO I = 1, 10 or DOI=1,10
Both were considered to be the same (this is the Fortran for the time of the late 60's early 70's).
In PL/I spaces did matter. Taking the same example above:
DO I = 1 to 100; OR DOI=1 to 100;
are very different statements; I think the second one won't even compile.
Perhaps you are thinking of Keywords. Like all languages, PL/I has keywords, (such as DECLARE, DO, IF, END, and so on), but, because PL/I had so many keywords, the language designers decided that none of them were to be RESERVED. Going to the Fortran example above, the word DO is a keyword AND is reserved, and cannot be used for any other purpose but in a DO statement. In PL/I, one can use DO in a do statement and also as a variable. The "headache" in writing a PL/I compiler was the requirement that it had to figure out from the context whether a word was being used as a keyword or not.
The example that I remember from back in the day was this. The following is a perfectly valid PL/I statement (because no keywords are reserved):
IF IF = EQUALS THEN THEN = ELSE; ELSE ELSE = IF;
Cheers RSzoc 01:02, 26 November 2006 (UTC)
Adding to our understanding of the name (I would rather PL/1, since that was intended), "A Genealogy of Computer Languages" by James Haddock says "In 1964, IBM was developing its System/360. Never happy with ALGOL, they wanted to have a dialect of their own as a system implementation language, but with the ability to handle COBOL style applications. The result was PL/1 (they also copyrighted the names PL/2 through PL/100 just in case)." Gc9580 ( talk) 06:12, 21 March 2009 (UTC)
IF(IF.EQ.THEN) THEN THEN=ELSE ELSE ELSE=IF ENDIF
(I believe that is right, but didn't actually try it.) Gah4 ( talk) 22:11, 13 March 2019 (UTC)
References
Is 1964 the year PL/1 was first developed? Same as System/360? -- sabre23t 02:17, 19 Sep 2004 (UTC)
The PL/I language specification was still being developed in 1964, and there was no PL/I compiler available from IBM when S/360 and OS/360 were released. Documentation for S/360 and OS/360 was available in 1964, but the first systems - at the lower end - did not begin shipping till 1965. My personal recollection is that IBM's production of system 360s didn't begin in high volume until 1968 or so.
RSzoc
01:08, 26 November 2006 (UTC)
---
I was working on PL/I for IBM in England in 1964-1965, and I recall writing assembler language interrupt processing routines for the "Tape Operating System" TOS, that was available for the machine before OS/360, but of course not for release.
The 'F' in PL/I F refers to the fact that it was intended to run on a machine with only 64K (64 Kib in the ugly new abbreviation) of 'core', which was our random access memory. That's with an OS as well, of 20 K.
The '360' of System 360 was intended to imply completeness, as in a full circle of 360 degrees, which makes the same nonsense of S/370 and S/390 as "I support you 110%".
We had an apocryphal story that IBM UK was warned by the National Physical Laboratory that if they did not drop the NPL name, the real NPL would publish a standard or something called Infernal Bloody Mess, to be known by its initials.
As for the reluctance to adopt PL/I, there was a feeling at Hursley that part of the reluctance was the "Not Written Here' attitude of IBM USA.
DaveyHume (
talk)
18:04, 9 March 2016 (UTC)
As for Multics and MIT, the web site of http://www.multicians.org/pl1-raf.html states that "Multics PL/I" was based on an IBM language spec that was not available until 1968. Again, I believe the difference is the time difference between when specifications are made (e.g., 1965 in the case of Multics) and when a final software product containing that specification is actually produced. The above referenced Web site states that the Multics PL/I compiler was developed in 18 months. If we take March, 1968 as the starting point - when the PL/I language spec used by MIT was available, and add 18 months, we get September 1969 as when Multics Pl/I compiler was actually available. MPearl - what is your reference for the 1964 date?? RSzoc 01:08, 26 November 2006 (UTC)
As an aside, UNIX was named as a form of word play for Multics. Because the Multics OS was so big - many computer types felt at the time - Dennis Ritchie and Ken Thompson at Bell Labs named their OS Unix, implying small and lean.
Now, of course, all OSes are pretty much out of control, with nothing begin small and lean, except for maybe whatever drives microwave ovens (that last sentence is an editorial comment by me - feel free to snip it out)... RSzoc 18:52, 18 November 2006 (UTC)
The first ship of PL/I F by IBM was definitely 1966. I have added the chronology of the 5 releases of PL/I as they show some interesting PL/I history. F had the advantage that the language manual was being written on the floor above the one John Nash's F compiler team inhabited in "B block" in Hursley. There was an advertised DIgitek compiler that claimed to have shipped ahead of F - but the Multics team thought it was still vapourware, hence doing there own thing PL/I. EPL has been quoted as 1964, but it cannot have been a PL/I at this stage. I suspect it was a special purpose language initially and was adapted to PL/I as the PL/I Spec appeared in 1965/66,
—Preceding
unsigned comment added by
RogerofRomsey (
talk •
contribs)
16:06, 2 February 2010 (UTC)
The paragraphs on Multics and year implemented are still just plain wrong. The text states and implies that multics PL/I (or EPL) compiler was used in 1964. However, this reference ( http://www.multicians.org/pl1.html) shows that EPL is still not available as a working product even in 1966-1967. The other references for multics refer to the IBM Language Specification document in 1968 as the relevant language definition. So, my suggested timeline still holds. Until, at least, we get a statement from someone who was there and can state that:"We had a fully operational PL/I compiler in 196.... ". The other references cited in the section on Multics state things like: "The compiler implemented most features except for ... input and output... "... Which seems like a severe "to-do" item to make it usable... RSzoc ( talk) 01:45, 18 July 2010 (UTC)
Perhaps this isn't really important, but this article is actually a subpage: the subpage "I" of the article "PL". This obviously isn't the intention, but it seems to work alright. Deco 00:37, 17 Nov 2004 (UTC)
Perhaps a link to the current (Jan 2005) PLI newsletter would be useful? [1] -- ClemMcGann 00:50, 20 Mar 2005 (UTC)
This page contains the claim (in the "External links" section) that "The C programming language was heavily modelled after PL/I". Alas, this is untrue. The C Progamming Language (by Ritchie, Johnson, Lesk and Kernighan, 1977) says that "Many of its most important ideas stem from ... BCPL", and there is no mention of PL/I. As for BCPL, the BCPL Reference Manual (by Richards, Evans and Maybee, 1974) says that "BCPL is related to CPL", and again no mention of PL/I. (The CPL documents cited date from 1963/65, making it impossible for CPL to have been influenced by PL/I.) So I am going to remove that claim. Noel (talk) 22:20, 12 Apr 2005 (UTC)
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)
I know it's nitpicking, but IBM didn't refer to System/360 as the System/360. It was just System/360. My reference is a 1964 copy of the IBM Systems Journal where the entire architecture of the machine was described in Iverson notation. Shoaler 5 July 2005 17:22 (UTC)
I think I disagree with the revert done to my change of the adjective "powerful" to "ambitious." I appreciate the differences between PL/1 and C, but both are NP-complete languages, and I think the use of the word "powerful" in this context is misleading; it gives a false impression, and is (in my opinion) a bit too cheerleading of a word to lead off an article with.
I prefer "ambitious" because it more accurately captures the scope of PL/1 as a featureful language, without reference to the perceived "power" of the language (which really, could mean anything).
Thoughts? I'm also open to other suggestions. As a test, I've changed powerful to "feature-rich", which I think also captures the true nature of the distinction. Nandesuka 15:27, 15 July 2005 (UTC)
The article reads: PL/I was probably the first commercial language where the compiler was written in the language to be compiled.
First off, thank you for getting back to me. I guess the easiest way to bring up concerns about factual information like that is to bring it up in the discussion pages, but the way you removed the line without a clear comment did make it impossible to know that you were doing so to dispute the timeline.
I suppose that some of this is my fault for confusing two languages. I could have corrected the error when I first saw it. I actually had a counter-example from NELIAC, which was first publicly announced in 1958, based on publications from the Naval Research Laboratory. What year was the compiler that you were refering to written?
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)
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)
Also, AREAs can be read or written as a block, and the offsets will still be valid. Additionally they make it easy to clean up storage by just deleting the AREA, rather than having to delete lots of separate data items individually. Peter Flass ( talk) 21:13, 20 August 2011 (UTC)
As an ordinary programmer who has read up on PL/1 after learning C and Pascal, I would like to suggest 3 more reasons that the language is not more widely accepted. (1) The requirement that a subprogram could be embedded ANYWHERE inside a parent routine put another burden on the compiler writer, who would potentially have to save off data on the parent routine and then restore it when the subprogram finished. The feature itself was overkill; Pascal (and later ADA) confined subprograms to the declaration area with no loss of power.. (2) Although amazingly full of built-in data types, the language design completely missed out on the concept of the user-defined datatype, a very hot topic in the '70s. The only way that a programmer could declare two variables of the same complicated type was to use a clumsy "A LIKE B" mechanism, which would be a maintenance headache -- suppose B turned out to be obsolete during a later revision? (3) Wierd rules such as writing TRUE as '1'B, when both COBOL and FORTRAN already had much clearer syntax. CharlesTheBold 03:28, 30 July 2007 (UTC)
struct
and Pascal record
. This was a very common concept in the 1970s, and no serious language lacked it. PL/I even had C's *struct
, using BASED(pointer)
, which was uncommon for a HLL of the time (of course, Assembler programmers used DSECTs for exactly that all the time). And nobody coded DECLARE A LIKE B;
unless B was a structure and existed solely for that purpose.DECLARE TRUE BIT INIT('1'B); DECLARE FALSE BIT INIT('0'B);
? And from a boolean perspective, C's "true is 1, false is anything else" concept is just wacky.Thank you for the historical perspective. I was of course evaluating the language from the point of view of 2007. I can tell the language was a powerful tool in the 1970's when compared to COBOL and FORTRAN. I understood about PL/1 structures, my point being that PL/1 seemed to operate by cloning a sample structure rather than instantiating a template -- this is a theoetical point which probably didn't make much practical difference in writing programs. CharlesTheBold 03:08, 10 August 2007 (UTC)
I worked for IBM on the mathematical library subroutines for the PL/I library, when hardware floating point didn't have exponential and trigonometric functions. I think I keypunched cards from my own handwritten programs. It could cost you a day to submit a program to the machine, and have it come back with syntax errors. It is now more economical of a programmer's time to let the computer report them in less than a minute.
Is the semi-colon missing from the PUT SKIP line of the second example intentional? -- MarkMLl ( talk) 13:49, 25 December 2007 (UTC)
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)
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)
One thing is to add complexity, other to add verbosity. PL/1 added new features needed for modular design (COBOL is was poor in that aspect, Fortran was modular), more flexibility to represent data structures (Fortran was very poor in that sense, although a tricky use of format allows to represent records, but it lacks pointers, COBOL also lacks pointers although it had arrays, records and unions), PL/1 also had math operations, (Fortran was the king, COBOL has a very poor design, it lacks math operations, only restricted to the basic arithmetic operators using English, although the compute verb allowed formulas, but forget other computations like logarithms needed to compute interest rates but that was not considered business oriented).
Maybe PL/1 seemed too verbose to Fortran programmers. If one browse books on numerical methods of those years, the prevalent language is Fortran. However some books on Data Structures or other areas requiring a more elaborated data structures, had some PL/1 examples. I don't know any of such books that use COBOL, I wouldn't because it lacks pointers and recursion (one has to use arrays and indexes), although it has records and unions. (I knew about a rare brand registering program written in COBOL performing syntax analysis and phonetic comparison with registered brands.)
Fortran is used in some books, implementing trees with arrays and indexes, also implementing stacks with arrays to handle recursion. And those requiring more elaborated data representation, like the IA researchers, used Lisp, small, elegant and powerful despite of all the parenthesis.
The business programmers had COBOL, although PL/1 is less verbose than it, it has features like generic and entry that allow overloading, something that they rarely think about in a world predominated by batch processing of files. They just scanned records in files to add, delete, and change them according to other transactions file. Although unions allow to represent different kinds of records, is rare to see them in those batch programs (COBOL has unions). Why should them learn PL/1?
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)
Parts of the history section sound extremely suspicious when you add them together, for instance it says that PL/I was developed in Europe, but later "PL/I was designed by a committee drawn from IBM programmers and users drawn from across the United States".
While it is possible that the language was "designed" in the USA with input only from USA and then implemented in Europe that sounds a) like a roundabout way of doing thins b) very unlike IBM c) means that the implementers had no input on the language etc etc etc
There are other strange things going on on the page reiknir ( talk) 03:45, 26 November 2009 (UTC)
RogerofRomsey ( talk) 18:29, 15 January 2010 (UTC)
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)
Comments welcomed on my talk RogerofRomsey ( talk) 21:05, 26 January 2010 (UTC)
The language summary is keyed to the Standard to avoid contention. But there were important elements missed out in the standard, and significant developments have occurred since. To capture these I am adding an Evolution of the language section. —Preceding unsigned comment added by RogerofRomsey ( talk • contribs) 15:25, 28 January 2010 (UTC)
The Variable names section is redundant - the fact that there are no reserved words in PL/I has been made already, and this example doesn't add anything to that. I would expect most compilers to warn the user when IF,THEN,ELSE, and DO are used as identifiers. Let's not tempt people to write bad programs.
RogerofRomsey (
talk)
16:20, 2 February 2010 (UTC)
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)
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)
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)
I have put in further substructuring to help make sense of the lists of compilers
RogerofRomsey ( talk) 09:45, 5 February 2010 (UTC)
I have added a large section on the current (2010) IBM PL/I compiler - a beast with several names and supporting all IBM platforms including AIX, Linux and Z/OS. The section risks dominating the implementation section, but I see no alternative as it is the main IBM vehicle and there is so much new function in it. There is no Standard for the added functions, so the extensions have been placed in the Implementation section. It would help if the major extensions to PL/I made by Kednos and Liant/MicroFocus were included. Anyone have any material?
I may have made mistakes in the addition as I have no experience with the new product.
RogerofRomsey (
talk)
17:58, 9 March 2010 (UTC)
I removed the following inline text by RogerofRomsey from the "'On' block error trapping" section of the article:
I also adjusted the text a bit to reflect his point. The section still needs work, though. — ( talk) 18:43, 19 April 2010 (UTC)
Thanks. RogerofRomsey ( talk) 12:36, 20 April 2010 (UTC)
I have added a larger section covering more rationale and more of the language. Hope it includes what Loadmaster wanted to cover. RogerofRomsey ( talk) 17:20, 20 April 2010 (UTC)
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)
Seems biased against the customers, using weasel words to describe their views and blaming them for the language's faults:
Programmer Issues
• "Many programmers were slow to move" // were they slow or did they decide not to move?
• "a perceived complexity" // so it's the programmers' fault, or is it complex?
• "Programmers were sharply divided ... with significant tension and even dislike between the groups" // it's the programmers again
• "Both COBOL and FORTRAN programmers ... were somewhat intimidated by the language and disinclined to adopt it." // more weasel words
• "jaundiced view of PL/I, and often an active dislike for the language." // ditto
QuentinUK (
talk)
14:11, 14 June 2011 (UTC)
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)
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)
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)
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)
Very true. I shall alter it. FreeFlow99 ( talk) 11:27, 11 February 2020 (UTC)
"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)
I noticed the citation in the first paragraph ([1], which points to "Sturm, Eberhard (2009). The New PL/I. Vieweg+Teubner. ISBN 978-3-8348-0726-7.") 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)
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)
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)
Is PL/I the first compiled language with array expressions? Gah4 ( talk) 02:43, 17 May 2017 (UTC)
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:
{{
dead link}}
tag to
http://www.kednos.com/{{
dead link}}
tag to
http://www.bitsavers.org/pdf/ibm/360/pli/C28-6571-1_PL_I_Language_Specifications_Jul65.pdfIBM{{
dead link}}
tag to
http://www.kednos.com/When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— InternetArchiveBot ( Report bug) 21:50, 1 December 2017 (UTC)
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)
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)
Regarding: Performance of compiled code competitive with that of Fortran (but this was not achieved) citation needed. 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)
Regarding: Orthogonality helps makes the language "large". clarification needed PL/I is good at allowing things if it made a tiny bit of sense to allow it. Fortran, on the other hand, seems to disallow things until it makes too much sense not to. One of my favorite is that PL/I allows COMPLEX and CHAR values in DO statements. (In the CHAR case, it does a string comparison.) The original language specification was mostly done before any compiler design was started, so it might not have been easy to know what features are easy and what are hard to implement. There are extra challenges related to multitasking, requiring in PL/I (F) a feature called pseudo-registers. (Task specific data.) Note also that there is not a restriction on nesting of internal procedures. I forget now if Fortran yet allows for nesting at all. And all for a compiler that is supposed to be able to run in 44K of core. Gah4 ( talk) 20:02, 11 February 2020 (UTC)
DO S=' 1' TO ' 100' BY '1';
Before that I tried DO IMAG(J)=1 TO 100;
which also works. Is PL/I the only language with fixed point complex data types?
Gah4 (
talk)
00:21, 12 February 2020 (UTC)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)
The {{
Infobox programming language}} has |dialects=
PL/M,
XPL,
PL/P,
PL/C,
PL/S,
PL/AS,
PL/X,
PL-6,
PL/8,
EPL, SL/1
and |influenced=
CMS-2,
SP/k,
B,
REXX,
AS/400 Control Language,
C
.
B, C, CMS-2 and SL/1 look nothing like PL/I,; PL/M, PL/P, PL/AS, PL/S, PL/X, PL-6 and PL/8 are strongly influenced by PL/I but different enough not to call them dialects; and SP/k is arguably a set of PL/I dialects rather than just influenced by it. Shmuel (Seymour J.) Metz Username:Chatul ( talk) 16:31, 3 January 2021 (UTC)
Some sample PL/I code (modified from an example in a Digital Research PL/I manual):
if i = 0 then
x = 0;
else
do;
x = foo(x);
if i = 0 then
y = 0;
else
if i = 1 then
y = mumble(x,1,1);
else
y = mumble(x,1,i-1};
return;
end;
with the C equivalent
if (i == 0)
x = 0;
else
{
x = foo(x);
if (i == 0)
y = 0;
else
if (i == 1)
y = mumble(x,1,1);
else
y = mumble(x,1,i-1};
return;
}
Both languages appear to be "semicolons are terminators" languages. The one semicolon-related difference is that do
and end
are statements in PL/I, but {
and }
aren't statements in C, so, while do
and end
are followed by semicolons in PL/I, {
and }
aren't followed by semicolons in C.
Pascal, however, is a "semicolons are separators" language.
However, none of them put a semicolon before the else
.
Guy Harris (
talk)
09:31, 4 January 2021 (UTC)
{...}
in C or BEGIN; ... END;
in PL/I) is a statement; C does not require a terminating semicolon. Similarly, the C for statement does not require a terminating semicolon. In PL/I the semicolons are terminators but in C they are separators. Use an example with DO; ... END;
versus {...} and that should be clearer.$ cat foo.c int foo(int i) { i = i + 3; i = i + 17; return i } $ cc -c foo.c foo.c:6:10: error: expected ';' after return statement return i ^ ; 1 error generated.
begin
and the "block end" indicator end
are not statements (they're "statement brackets", to use the language of the "Revised Report on the Algorithmic Language Algol 60"). (Well, they can begin and end either a "compound statement" or a "block", depending on whether begin
is followed by declarations or not, but, at least as I read
Block (programming)#History, that distinction is historical.)DO
and END
are statements.DO
, the "block start" indicator BEGIN
, and the "group-and-block end" indicator END
are statements. I guess the difference is that a "group" has no name or allocation scope and a "block" does.begin
and end
as "symbols" that act as "statement brackets").{
and the "block end" indicator }
are not statements (so like ALGOL 60 and successors, except that the indicators aren't words :-)).DO
and the "block end" indicator END
are statements" is that every block ends with a semicolon, because the block terminator, being a statement, ends with a semicolon. That's not the case in ALGOL 60 or PASCAL, because 1) semicolons are separators and 2) the block terminator isn't a statement, and that's not the case in C because even though 1) semicolons are terminators, 2) the block terminator isn't a statement (there's a semicolon at the end of the last statement of a block, but that semicolon comes before the closing }
).IF scalar-expression THEN
and ELSE
there's a "unit", which is either a group (which can be a single statement or a DO-group) or a block, both of which always end with a semicolon. It's not there in Pascal because a single statement doesn't end with a semicolon (as semicolons are separators, not terminators) and a BEGIN/END block doesn't end with a semicolon (as semicolons aren't terminators and as END
isn't a statement in any case).BEGIN
is a statement in PL/I, but not in Pascal.for()
and while()
are just looping constructs that iterate a statement; "a statement" here includes a block, but the block structuring is independent of the looping. For do
...while()
in C, there's a block in the middle, after the do
and before the while()
- and, for more fun, there's a semicolon after while()
.if
and while
, and for the loop expressions in for
; there's probably a rationale somewhere, unless Dennis Ritchie was the only one who remembered it. As for commas in initializers, "It's a separator!" "It's a terminator!" "It's a floor wax and a dessert topping!" For enums, though, a comma is only a separator. Consistency FTW!
Guy Harris (
talk)
02:38, 5 January 2021 (UTC)IN
and OF
in COBOL, right?).(*a).b
" syntax, a->b
, from PL/I, too.
Guy Harris (
talk)
02:33, 6 January 2021 (UTC)
THEN
in an IF
statement can be more than one imperative statement, as can the "statement-2" after ELSE
, so I guess compound statements are defined by the IF
statement itself. That's COBOL 61, so that wasn't something new.PERFORM
doesn't, as of that version of COBOL, support an "inline" perform - you have to point it at a named "procedure". Those appear to have shown up in
COBOL-85.References
A statement, which is a string of characters, is always terminated by the special character, semicolon.
It is not clear what the intended as the distinction between PL/I dialect compilers and Special purpose and system PL/I compilers. Certainly HAL/S, PL/MP, PL/S, PL/8 and SPL/I are special purpose; equally clearly, PL/MP, PL/S and PL/8 are system languages. Shmuel (Seymour J.) Metz Username:Chatul ( talk) 14:10, 25 February 2021 (UTC)
Notes
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)
The article mentions
Series/1 twice; once with a reference and once with the text PL/G Subset for IBM Series/1 Mini Computer with Real Time extensions PL/I Language Reference GC34-0085-0
as a bullet item. I was going to correct the name to PL/I G subset when I realized that
If the text simply refers to the Series/1 PL/I [1] then I will revise it and include the citation. Can anybody clarify this? Thanks. Shmuel (Seymour J.) Metz Username:Chatul ( talk) 15:02, 28 February 2021 (UTC)
References
Prior to this edit, the second sentence of PL/I § Early history said
Business users were moving from Autocoders via COMTRAN to COBOL, while scientific users programmed in General Interpretive Programme (GIP), Fortran, ALGOL, GEORGE, and others.
The edit in question remove the General Interpretive Programme from the list as being an "uncited programming language without notability (no wikipedia page, few Google results, etc.)".
It appears, from some Google search results and from Pilot ACE § Software, that the General Interpretive Programme was originally written for the Pilot ACE and rewritten for the English Electric DEUCE; was it available? on other computers? The page for GEORGE doesn't mention any machine other than the DEUCE, either; was it available on other computers?
Autocoder refers to some IBM assembler languages, and COMTRAN refers to an IBM language that was one of the predecessors to COBOL; IBM may have been a bigger computer company than English Electric, but are those languages worth mentioning here, either?
The only languages mentioned there that don't appear to be specific to particular machines or particular vendors are COBOL, Fortran, and ALGOL (Fortran may have been developed by IBM, but it didn't remain IBM-only). How common were the ACE/DEUCE or even the IBM-only languages relative to COBOL. Fortran and ALGOL? Should those sentences focus on the more commonly used languages? Guy Harris ( talk) 07:22, 4 August 2021 (UTC)
References
Footnote 24 says the list-processing facilities were designed in 1966. The Wikipedia article on Harold (Bud) Lawson says he designed the facility in 1964. I believe the latter is correct and will change it unless proved wrong. Mdmi ( talk) 22:59, 16 November 2021 (UTC)
References
{{
cite book}}
: |work=
ignored (
help)
{{
cite book}}
: |work=
ignored (
help)
Talk:PL/I#Multics PL/I and derivatives claims EPL was a system programming language and a dialect of PL/I that had some capabilities absent in the original PL/I (like varying length strings).
with a citation of
Griswold, Ralph (1978).
"A history of the SNOBOL programming languages" (PDF). ACM SIGPLAN Notices. 13 (8). ACM: 275–308.
doi:
10.1145/960118.808393.
ISSN
0362-1340.
S2CID
5413577. Archived from
the original (PDF) on 2019-03-02., an article that has no connection to either Multics or PL/I, and the claim conflicts with
"Types of Data" (PDF),
NPL Technical Report (PDF), IBM, December 1964, p.
14, 320-0908, String data may be either CHARACTER string or BIT string and may be declared to be either fixed or varying length.
. --
Shmuel (Seymour J.) Metz Username:Chatul (
talk)
00:07, 30 December 2021 (UTC)
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)
Recent changes mention (at least in the edit summary) a connection between threads and tasks. As well as I know, that IBM calls tasks is closer to what many (especially Unix users) call a process. That has the complication what multiprocessing is ambiguous. (What do Unix users call it when they have more than one processor?) An important distinction is the overhead for creating and terminating one. Gah4 ( talk) 09:21, 9 May 2022 (UTC)
fork()
, although anything mapped MAP_PRIVATE
will be copy-on-write (as is now done on UN*Xes) because, to quote the current Single UNIX Specification for fork():
OK, maybe I am thinking of something different. I tend to think of threads as low overhead, and tasks in the OS/360 sense as high overhead, closer to Unix processes. I am not so sure now what Unix says about address space, and especially for fork() vs. vfork(). With threads, you should be able to create a large number of them, where I suspect OS/360 won't let you create hundreds or thousands of tasks. I am also not sure about scheduling of tasks, processes, and threads. Gah4 ( talk) 22:47, 10 May 2022 (UTC)
When programs issue fork() or spawn(), the BPXAS PROC found in SYS1.PROCLIB is used to provide a new address space. For a fork(), the system copies one process, called the parent process , into a new process, called the child process.
To allow the caller to control whether the spawned child process runs in a separate address space from the parent address space or in the same address space, the spawn service allows for the specification of the _BPX_SHAREAS environment variable.
fork()
duplicates the address space, so that subsequent changes to the address space in the parent don't affect the child, and vice versa.vfork()
isn't in the Single UNIX Specification; typically, it "loans" the parent's address space to the child, and temporarily blocks the parent process, with the expectation that the child process will do very little to the writable parts of the address space and will use one of the exec
calls to set up a new address space with a new program. Once it does that, the parent process is unblocked and can continue running, as if it were to modify the address space or any data in the address space, that won't affect the child. The macOS vfork()
man page has two paragraphs of warnings about stuff you should be careful not to do in the child after a vfork()
; those warnings may apply to some other UN*Xes as well. Other UN*Xes might implement vfork()
without the address-space loan, relying on copy-on-write for protection; however, they may still block the parent until an exec
call is done, because the code might implicitly or even explicitly require that the parent not run until the child finishes the setup and the exec
. (I have some memory of a UN*X where vfork()
originally was the same as fork()
, but some stuff using vfork()
broke because the parent ran before the exec
call was done, so the blocking was added. That might have been SunOS 4.0, but it's been so long that I can't be sure.)posix_spawn()
, which is similar to Windows CreateProcess()
in that it creates a child process that is running a new program, and that has some file descriptor/signal/etc. modifications done, but by the kernel rather than by the child process before running the program. No address space copying or loaning need be done there.The article mentions event-driven programming. I suppose that isn't so far off, but isn't what I would have thought about. There are EVENT variables, corresponding to the ECB ( Event Control Block) used by OS/360 and successors. That is mostly used for I/O, but also for task synchronization. For I/O, programs can used double (or more) buffering to keep the I/O system busy, and similarly with asynchronous I/O in PL/I. Gah4 ( talk) 23:38, 10 July 2023 (UTC)
WAIT
and POST
(which some other OSes have, with varying degrees of similarity and generality) would be hidden inside the event loop and in the code that delivers events, respectively.WAIT
statements and assignments to EVENT
variables, but it wouldn't necessarily involve programmers directly using WAIT
statements, for example.The goals for PL/I evolved during the early development of the language. Competitiveness with COBOL's record handling and report writing was required. The language's scope of usefulness grew to include system programming and event-driven programming.
ON
-units as event handlers; the ON
mechanism seems more like a (less-structured) form of
exception handling rather than anything like event-driven programming.
Guy Harris (
talk)
06:42, 11 July 2023 (UTC)
EVENT
variables, and named after the OS/360 ECB. In any case, we also need an article about the
Event Control Block. There are some fun endless channel programs for handling things like terminal I/O. That, and the handling of the I/O interrupt could do it.
Gah4 (
talk)
21:53, 11 July 2023 (UTC)
I thought, as noted above, that it is related to EVENT
variables, and named after the OS/360 ECB.
What is the "it" here? If it's "event-driven programming", I suspect it's unrelated to PL/I EVENT
variables or the OS/360 Event Control Block; I suspect, instead, that the notion of an "event" to which a computer system responds predates all of those terms.
Guy Harris (
talk)
23:12, 11 July 2023 (UTC)
In real-time data processing, events are often independent, not only of the computer, but of each other.
EVENT
"?
Guy Harris (
talk)
02:39, 12 July 2023 (UTC)
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
The inappropriate link to Talk:PL above is because of a technical restriction.
I deleted the following, which is not true:
IBM mainframes used separate symbols for the letter and the number. The 'I' in PL/I is a roman numeral. -- Simon J Kissane
I was trying to make a distinction between the character and the font. Unfortunately, I used the wrong symbols. It was the small "L" and the number "1" that used to identical font symbol (i.e., l and 1 look the same - more or less - even though I typed the "el" character first, and the "one" character second).
I was not intending to say that the characters were identical (i.e., had identical values in EBCDIC), merely that they looked the same. This was true for the Courier font ball used in IBM Selectrics, which were also used as operator terminals in some S/360 installations, and the font symbols may have been identical in the print cylinder in the 1403 printer. Because I don't have the original context - or don't know how to get my original contribution for the context, I'm not sure why I even brought up the character confusion thing... Cheers --17:29, 31 December 2006 (UTC) RSzoc
The bit about SABRE is from personal experience. I was offered (and turned down) a position with the SABRE project ca 1965. Don't know if they stayed w/ PL/I or changed to a different language.
The (military/aerospace) project I was on at the time would have used PL/I if it had been useable early enough. We went through major contortions to do a real-time/multi-tasking system requiring dynamic allocation of records (structs to you C weenies) in FORTRAN IV. Further, FORTRAN required 512K of RAM to compile, the PL/I compiler would work in 128K. -- Buz Cory
Evidently, the SABRE folks didn't get a really solid PL/I compiler for their platform until the early 1970s. They may have wanted to use PL/I earlier than that, but I can vouch that at least the portions of the system that American Airlines dealt with were almost entirely 7090 assembler before the early 1970s. (Working off my father's notes on this one; he wrote the compiler, so there's a chance his history is biased, of course.) -- Cliff Biffle
Not so sure about that "case insensitive" part. At that time virtually all work was done entirely in upper case due to hardware limitations. -- Buz Cory
Nice job on the history. Some references to written documents (which I understand may not exist) would be nice. If its personal experience, then say so. -- drj
Most of the history stuff I added is purely from memory. I read it somewhere. I wasn't even alive when PL/I was being developed. -- Simon J Kissane
A couple of inaccuracies in the "Retrospective section".
First, it states that the "user wouldn't know whether a statement was a declaration or a executable statement until one saw the period at the end. " The truth is that PL/I uses (and has always used) the semi-colon as a statement terminator. COBOL is that language that used periods. Additionally, a declaration statement ALWAYS begins with the keyword "DECLARE" or "DCL", so it's easy to figure out what kind of statement it is. Also, "format free" languages that could be spread along a number of lines before being terminated had been around since at least the early 1960/61 if not earlier. Even assembly language could span multiple lines if one put a "continuation" character in Column 72 of the "card".
Second, the article states that "the decision to make spaces unimportant, as in Fortran" (I paraphrase) is simply not true. In Fortran, spaces were truly irrelevant. Thus, one could write an "do statement" as follows:
DO I = 1, 10 or DOI=1,10
Both were considered to be the same (this is the Fortran for the time of the late 60's early 70's).
In PL/I spaces did matter. Taking the same example above:
DO I = 1 to 100; OR DOI=1 to 100;
are very different statements; I think the second one won't even compile.
Perhaps you are thinking of Keywords. Like all languages, PL/I has keywords, (such as DECLARE, DO, IF, END, and so on), but, because PL/I had so many keywords, the language designers decided that none of them were to be RESERVED. Going to the Fortran example above, the word DO is a keyword AND is reserved, and cannot be used for any other purpose but in a DO statement. In PL/I, one can use DO in a do statement and also as a variable. The "headache" in writing a PL/I compiler was the requirement that it had to figure out from the context whether a word was being used as a keyword or not.
The example that I remember from back in the day was this. The following is a perfectly valid PL/I statement (because no keywords are reserved):
IF IF = EQUALS THEN THEN = ELSE; ELSE ELSE = IF;
Cheers RSzoc 01:02, 26 November 2006 (UTC)
Adding to our understanding of the name (I would rather PL/1, since that was intended), "A Genealogy of Computer Languages" by James Haddock says "In 1964, IBM was developing its System/360. Never happy with ALGOL, they wanted to have a dialect of their own as a system implementation language, but with the ability to handle COBOL style applications. The result was PL/1 (they also copyrighted the names PL/2 through PL/100 just in case)." Gc9580 ( talk) 06:12, 21 March 2009 (UTC)
IF(IF.EQ.THEN) THEN THEN=ELSE ELSE ELSE=IF ENDIF
(I believe that is right, but didn't actually try it.) Gah4 ( talk) 22:11, 13 March 2019 (UTC)
References
Is 1964 the year PL/1 was first developed? Same as System/360? -- sabre23t 02:17, 19 Sep 2004 (UTC)
The PL/I language specification was still being developed in 1964, and there was no PL/I compiler available from IBM when S/360 and OS/360 were released. Documentation for S/360 and OS/360 was available in 1964, but the first systems - at the lower end - did not begin shipping till 1965. My personal recollection is that IBM's production of system 360s didn't begin in high volume until 1968 or so.
RSzoc
01:08, 26 November 2006 (UTC)
---
I was working on PL/I for IBM in England in 1964-1965, and I recall writing assembler language interrupt processing routines for the "Tape Operating System" TOS, that was available for the machine before OS/360, but of course not for release.
The 'F' in PL/I F refers to the fact that it was intended to run on a machine with only 64K (64 Kib in the ugly new abbreviation) of 'core', which was our random access memory. That's with an OS as well, of 20 K.
The '360' of System 360 was intended to imply completeness, as in a full circle of 360 degrees, which makes the same nonsense of S/370 and S/390 as "I support you 110%".
We had an apocryphal story that IBM UK was warned by the National Physical Laboratory that if they did not drop the NPL name, the real NPL would publish a standard or something called Infernal Bloody Mess, to be known by its initials.
As for the reluctance to adopt PL/I, there was a feeling at Hursley that part of the reluctance was the "Not Written Here' attitude of IBM USA.
DaveyHume (
talk)
18:04, 9 March 2016 (UTC)
As for Multics and MIT, the web site of http://www.multicians.org/pl1-raf.html states that "Multics PL/I" was based on an IBM language spec that was not available until 1968. Again, I believe the difference is the time difference between when specifications are made (e.g., 1965 in the case of Multics) and when a final software product containing that specification is actually produced. The above referenced Web site states that the Multics PL/I compiler was developed in 18 months. If we take March, 1968 as the starting point - when the PL/I language spec used by MIT was available, and add 18 months, we get September 1969 as when Multics Pl/I compiler was actually available. MPearl - what is your reference for the 1964 date?? RSzoc 01:08, 26 November 2006 (UTC)
As an aside, UNIX was named as a form of word play for Multics. Because the Multics OS was so big - many computer types felt at the time - Dennis Ritchie and Ken Thompson at Bell Labs named their OS Unix, implying small and lean.
Now, of course, all OSes are pretty much out of control, with nothing begin small and lean, except for maybe whatever drives microwave ovens (that last sentence is an editorial comment by me - feel free to snip it out)... RSzoc 18:52, 18 November 2006 (UTC)
The first ship of PL/I F by IBM was definitely 1966. I have added the chronology of the 5 releases of PL/I as they show some interesting PL/I history. F had the advantage that the language manual was being written on the floor above the one John Nash's F compiler team inhabited in "B block" in Hursley. There was an advertised DIgitek compiler that claimed to have shipped ahead of F - but the Multics team thought it was still vapourware, hence doing there own thing PL/I. EPL has been quoted as 1964, but it cannot have been a PL/I at this stage. I suspect it was a special purpose language initially and was adapted to PL/I as the PL/I Spec appeared in 1965/66,
—Preceding
unsigned comment added by
RogerofRomsey (
talk •
contribs)
16:06, 2 February 2010 (UTC)
The paragraphs on Multics and year implemented are still just plain wrong. The text states and implies that multics PL/I (or EPL) compiler was used in 1964. However, this reference ( http://www.multicians.org/pl1.html) shows that EPL is still not available as a working product even in 1966-1967. The other references for multics refer to the IBM Language Specification document in 1968 as the relevant language definition. So, my suggested timeline still holds. Until, at least, we get a statement from someone who was there and can state that:"We had a fully operational PL/I compiler in 196.... ". The other references cited in the section on Multics state things like: "The compiler implemented most features except for ... input and output... "... Which seems like a severe "to-do" item to make it usable... RSzoc ( talk) 01:45, 18 July 2010 (UTC)
Perhaps this isn't really important, but this article is actually a subpage: the subpage "I" of the article "PL". This obviously isn't the intention, but it seems to work alright. Deco 00:37, 17 Nov 2004 (UTC)
Perhaps a link to the current (Jan 2005) PLI newsletter would be useful? [1] -- ClemMcGann 00:50, 20 Mar 2005 (UTC)
This page contains the claim (in the "External links" section) that "The C programming language was heavily modelled after PL/I". Alas, this is untrue. The C Progamming Language (by Ritchie, Johnson, Lesk and Kernighan, 1977) says that "Many of its most important ideas stem from ... BCPL", and there is no mention of PL/I. As for BCPL, the BCPL Reference Manual (by Richards, Evans and Maybee, 1974) says that "BCPL is related to CPL", and again no mention of PL/I. (The CPL documents cited date from 1963/65, making it impossible for CPL to have been influenced by PL/I.) So I am going to remove that claim. Noel (talk) 22:20, 12 Apr 2005 (UTC)
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)
I know it's nitpicking, but IBM didn't refer to System/360 as the System/360. It was just System/360. My reference is a 1964 copy of the IBM Systems Journal where the entire architecture of the machine was described in Iverson notation. Shoaler 5 July 2005 17:22 (UTC)
I think I disagree with the revert done to my change of the adjective "powerful" to "ambitious." I appreciate the differences between PL/1 and C, but both are NP-complete languages, and I think the use of the word "powerful" in this context is misleading; it gives a false impression, and is (in my opinion) a bit too cheerleading of a word to lead off an article with.
I prefer "ambitious" because it more accurately captures the scope of PL/1 as a featureful language, without reference to the perceived "power" of the language (which really, could mean anything).
Thoughts? I'm also open to other suggestions. As a test, I've changed powerful to "feature-rich", which I think also captures the true nature of the distinction. Nandesuka 15:27, 15 July 2005 (UTC)
The article reads: PL/I was probably the first commercial language where the compiler was written in the language to be compiled.
First off, thank you for getting back to me. I guess the easiest way to bring up concerns about factual information like that is to bring it up in the discussion pages, but the way you removed the line without a clear comment did make it impossible to know that you were doing so to dispute the timeline.
I suppose that some of this is my fault for confusing two languages. I could have corrected the error when I first saw it. I actually had a counter-example from NELIAC, which was first publicly announced in 1958, based on publications from the Naval Research Laboratory. What year was the compiler that you were refering to written?
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)
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)
Also, AREAs can be read or written as a block, and the offsets will still be valid. Additionally they make it easy to clean up storage by just deleting the AREA, rather than having to delete lots of separate data items individually. Peter Flass ( talk) 21:13, 20 August 2011 (UTC)
As an ordinary programmer who has read up on PL/1 after learning C and Pascal, I would like to suggest 3 more reasons that the language is not more widely accepted. (1) The requirement that a subprogram could be embedded ANYWHERE inside a parent routine put another burden on the compiler writer, who would potentially have to save off data on the parent routine and then restore it when the subprogram finished. The feature itself was overkill; Pascal (and later ADA) confined subprograms to the declaration area with no loss of power.. (2) Although amazingly full of built-in data types, the language design completely missed out on the concept of the user-defined datatype, a very hot topic in the '70s. The only way that a programmer could declare two variables of the same complicated type was to use a clumsy "A LIKE B" mechanism, which would be a maintenance headache -- suppose B turned out to be obsolete during a later revision? (3) Wierd rules such as writing TRUE as '1'B, when both COBOL and FORTRAN already had much clearer syntax. CharlesTheBold 03:28, 30 July 2007 (UTC)
struct
and Pascal record
. This was a very common concept in the 1970s, and no serious language lacked it. PL/I even had C's *struct
, using BASED(pointer)
, which was uncommon for a HLL of the time (of course, Assembler programmers used DSECTs for exactly that all the time). And nobody coded DECLARE A LIKE B;
unless B was a structure and existed solely for that purpose.DECLARE TRUE BIT INIT('1'B); DECLARE FALSE BIT INIT('0'B);
? And from a boolean perspective, C's "true is 1, false is anything else" concept is just wacky.Thank you for the historical perspective. I was of course evaluating the language from the point of view of 2007. I can tell the language was a powerful tool in the 1970's when compared to COBOL and FORTRAN. I understood about PL/1 structures, my point being that PL/1 seemed to operate by cloning a sample structure rather than instantiating a template -- this is a theoetical point which probably didn't make much practical difference in writing programs. CharlesTheBold 03:08, 10 August 2007 (UTC)
I worked for IBM on the mathematical library subroutines for the PL/I library, when hardware floating point didn't have exponential and trigonometric functions. I think I keypunched cards from my own handwritten programs. It could cost you a day to submit a program to the machine, and have it come back with syntax errors. It is now more economical of a programmer's time to let the computer report them in less than a minute.
Is the semi-colon missing from the PUT SKIP line of the second example intentional? -- MarkMLl ( talk) 13:49, 25 December 2007 (UTC)
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)
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)
One thing is to add complexity, other to add verbosity. PL/1 added new features needed for modular design (COBOL is was poor in that aspect, Fortran was modular), more flexibility to represent data structures (Fortran was very poor in that sense, although a tricky use of format allows to represent records, but it lacks pointers, COBOL also lacks pointers although it had arrays, records and unions), PL/1 also had math operations, (Fortran was the king, COBOL has a very poor design, it lacks math operations, only restricted to the basic arithmetic operators using English, although the compute verb allowed formulas, but forget other computations like logarithms needed to compute interest rates but that was not considered business oriented).
Maybe PL/1 seemed too verbose to Fortran programmers. If one browse books on numerical methods of those years, the prevalent language is Fortran. However some books on Data Structures or other areas requiring a more elaborated data structures, had some PL/1 examples. I don't know any of such books that use COBOL, I wouldn't because it lacks pointers and recursion (one has to use arrays and indexes), although it has records and unions. (I knew about a rare brand registering program written in COBOL performing syntax analysis and phonetic comparison with registered brands.)
Fortran is used in some books, implementing trees with arrays and indexes, also implementing stacks with arrays to handle recursion. And those requiring more elaborated data representation, like the IA researchers, used Lisp, small, elegant and powerful despite of all the parenthesis.
The business programmers had COBOL, although PL/1 is less verbose than it, it has features like generic and entry that allow overloading, something that they rarely think about in a world predominated by batch processing of files. They just scanned records in files to add, delete, and change them according to other transactions file. Although unions allow to represent different kinds of records, is rare to see them in those batch programs (COBOL has unions). Why should them learn PL/1?
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)
Parts of the history section sound extremely suspicious when you add them together, for instance it says that PL/I was developed in Europe, but later "PL/I was designed by a committee drawn from IBM programmers and users drawn from across the United States".
While it is possible that the language was "designed" in the USA with input only from USA and then implemented in Europe that sounds a) like a roundabout way of doing thins b) very unlike IBM c) means that the implementers had no input on the language etc etc etc
There are other strange things going on on the page reiknir ( talk) 03:45, 26 November 2009 (UTC)
RogerofRomsey ( talk) 18:29, 15 January 2010 (UTC)
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)
Comments welcomed on my talk RogerofRomsey ( talk) 21:05, 26 January 2010 (UTC)
The language summary is keyed to the Standard to avoid contention. But there were important elements missed out in the standard, and significant developments have occurred since. To capture these I am adding an Evolution of the language section. —Preceding unsigned comment added by RogerofRomsey ( talk • contribs) 15:25, 28 January 2010 (UTC)
The Variable names section is redundant - the fact that there are no reserved words in PL/I has been made already, and this example doesn't add anything to that. I would expect most compilers to warn the user when IF,THEN,ELSE, and DO are used as identifiers. Let's not tempt people to write bad programs.
RogerofRomsey (
talk)
16:20, 2 February 2010 (UTC)
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)
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)
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)
I have put in further substructuring to help make sense of the lists of compilers
RogerofRomsey ( talk) 09:45, 5 February 2010 (UTC)
I have added a large section on the current (2010) IBM PL/I compiler - a beast with several names and supporting all IBM platforms including AIX, Linux and Z/OS. The section risks dominating the implementation section, but I see no alternative as it is the main IBM vehicle and there is so much new function in it. There is no Standard for the added functions, so the extensions have been placed in the Implementation section. It would help if the major extensions to PL/I made by Kednos and Liant/MicroFocus were included. Anyone have any material?
I may have made mistakes in the addition as I have no experience with the new product.
RogerofRomsey (
talk)
17:58, 9 March 2010 (UTC)
I removed the following inline text by RogerofRomsey from the "'On' block error trapping" section of the article:
I also adjusted the text a bit to reflect his point. The section still needs work, though. — ( talk) 18:43, 19 April 2010 (UTC)
Thanks. RogerofRomsey ( talk) 12:36, 20 April 2010 (UTC)
I have added a larger section covering more rationale and more of the language. Hope it includes what Loadmaster wanted to cover. RogerofRomsey ( talk) 17:20, 20 April 2010 (UTC)
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)
Seems biased against the customers, using weasel words to describe their views and blaming them for the language's faults:
Programmer Issues
• "Many programmers were slow to move" // were they slow or did they decide not to move?
• "a perceived complexity" // so it's the programmers' fault, or is it complex?
• "Programmers were sharply divided ... with significant tension and even dislike between the groups" // it's the programmers again
• "Both COBOL and FORTRAN programmers ... were somewhat intimidated by the language and disinclined to adopt it." // more weasel words
• "jaundiced view of PL/I, and often an active dislike for the language." // ditto
QuentinUK (
talk)
14:11, 14 June 2011 (UTC)
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)
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)
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)
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)
Very true. I shall alter it. FreeFlow99 ( talk) 11:27, 11 February 2020 (UTC)
"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)
I noticed the citation in the first paragraph ([1], which points to "Sturm, Eberhard (2009). The New PL/I. Vieweg+Teubner. ISBN 978-3-8348-0726-7.") 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)
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)
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)
Is PL/I the first compiled language with array expressions? Gah4 ( talk) 02:43, 17 May 2017 (UTC)
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:
{{
dead link}}
tag to
http://www.kednos.com/{{
dead link}}
tag to
http://www.bitsavers.org/pdf/ibm/360/pli/C28-6571-1_PL_I_Language_Specifications_Jul65.pdfIBM{{
dead link}}
tag to
http://www.kednos.com/When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— InternetArchiveBot ( Report bug) 21:50, 1 December 2017 (UTC)
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)
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)
Regarding: Performance of compiled code competitive with that of Fortran (but this was not achieved) citation needed. 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)
Regarding: Orthogonality helps makes the language "large". clarification needed PL/I is good at allowing things if it made a tiny bit of sense to allow it. Fortran, on the other hand, seems to disallow things until it makes too much sense not to. One of my favorite is that PL/I allows COMPLEX and CHAR values in DO statements. (In the CHAR case, it does a string comparison.) The original language specification was mostly done before any compiler design was started, so it might not have been easy to know what features are easy and what are hard to implement. There are extra challenges related to multitasking, requiring in PL/I (F) a feature called pseudo-registers. (Task specific data.) Note also that there is not a restriction on nesting of internal procedures. I forget now if Fortran yet allows for nesting at all. And all for a compiler that is supposed to be able to run in 44K of core. Gah4 ( talk) 20:02, 11 February 2020 (UTC)
DO S=' 1' TO ' 100' BY '1';
Before that I tried DO IMAG(J)=1 TO 100;
which also works. Is PL/I the only language with fixed point complex data types?
Gah4 (
talk)
00:21, 12 February 2020 (UTC)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)
The {{
Infobox programming language}} has |dialects=
PL/M,
XPL,
PL/P,
PL/C,
PL/S,
PL/AS,
PL/X,
PL-6,
PL/8,
EPL, SL/1
and |influenced=
CMS-2,
SP/k,
B,
REXX,
AS/400 Control Language,
C
.
B, C, CMS-2 and SL/1 look nothing like PL/I,; PL/M, PL/P, PL/AS, PL/S, PL/X, PL-6 and PL/8 are strongly influenced by PL/I but different enough not to call them dialects; and SP/k is arguably a set of PL/I dialects rather than just influenced by it. Shmuel (Seymour J.) Metz Username:Chatul ( talk) 16:31, 3 January 2021 (UTC)
Some sample PL/I code (modified from an example in a Digital Research PL/I manual):
if i = 0 then
x = 0;
else
do;
x = foo(x);
if i = 0 then
y = 0;
else
if i = 1 then
y = mumble(x,1,1);
else
y = mumble(x,1,i-1};
return;
end;
with the C equivalent
if (i == 0)
x = 0;
else
{
x = foo(x);
if (i == 0)
y = 0;
else
if (i == 1)
y = mumble(x,1,1);
else
y = mumble(x,1,i-1};
return;
}
Both languages appear to be "semicolons are terminators" languages. The one semicolon-related difference is that do
and end
are statements in PL/I, but {
and }
aren't statements in C, so, while do
and end
are followed by semicolons in PL/I, {
and }
aren't followed by semicolons in C.
Pascal, however, is a "semicolons are separators" language.
However, none of them put a semicolon before the else
.
Guy Harris (
talk)
09:31, 4 January 2021 (UTC)
{...}
in C or BEGIN; ... END;
in PL/I) is a statement; C does not require a terminating semicolon. Similarly, the C for statement does not require a terminating semicolon. In PL/I the semicolons are terminators but in C they are separators. Use an example with DO; ... END;
versus {...} and that should be clearer.$ cat foo.c int foo(int i) { i = i + 3; i = i + 17; return i } $ cc -c foo.c foo.c:6:10: error: expected ';' after return statement return i ^ ; 1 error generated.
begin
and the "block end" indicator end
are not statements (they're "statement brackets", to use the language of the "Revised Report on the Algorithmic Language Algol 60"). (Well, they can begin and end either a "compound statement" or a "block", depending on whether begin
is followed by declarations or not, but, at least as I read
Block (programming)#History, that distinction is historical.)DO
and END
are statements.DO
, the "block start" indicator BEGIN
, and the "group-and-block end" indicator END
are statements. I guess the difference is that a "group" has no name or allocation scope and a "block" does.begin
and end
as "symbols" that act as "statement brackets").{
and the "block end" indicator }
are not statements (so like ALGOL 60 and successors, except that the indicators aren't words :-)).DO
and the "block end" indicator END
are statements" is that every block ends with a semicolon, because the block terminator, being a statement, ends with a semicolon. That's not the case in ALGOL 60 or PASCAL, because 1) semicolons are separators and 2) the block terminator isn't a statement, and that's not the case in C because even though 1) semicolons are terminators, 2) the block terminator isn't a statement (there's a semicolon at the end of the last statement of a block, but that semicolon comes before the closing }
).IF scalar-expression THEN
and ELSE
there's a "unit", which is either a group (which can be a single statement or a DO-group) or a block, both of which always end with a semicolon. It's not there in Pascal because a single statement doesn't end with a semicolon (as semicolons are separators, not terminators) and a BEGIN/END block doesn't end with a semicolon (as semicolons aren't terminators and as END
isn't a statement in any case).BEGIN
is a statement in PL/I, but not in Pascal.for()
and while()
are just looping constructs that iterate a statement; "a statement" here includes a block, but the block structuring is independent of the looping. For do
...while()
in C, there's a block in the middle, after the do
and before the while()
- and, for more fun, there's a semicolon after while()
.if
and while
, and for the loop expressions in for
; there's probably a rationale somewhere, unless Dennis Ritchie was the only one who remembered it. As for commas in initializers, "It's a separator!" "It's a terminator!" "It's a floor wax and a dessert topping!" For enums, though, a comma is only a separator. Consistency FTW!
Guy Harris (
talk)
02:38, 5 January 2021 (UTC)IN
and OF
in COBOL, right?).(*a).b
" syntax, a->b
, from PL/I, too.
Guy Harris (
talk)
02:33, 6 January 2021 (UTC)
THEN
in an IF
statement can be more than one imperative statement, as can the "statement-2" after ELSE
, so I guess compound statements are defined by the IF
statement itself. That's COBOL 61, so that wasn't something new.PERFORM
doesn't, as of that version of COBOL, support an "inline" perform - you have to point it at a named "procedure". Those appear to have shown up in
COBOL-85.References
A statement, which is a string of characters, is always terminated by the special character, semicolon.
It is not clear what the intended as the distinction between PL/I dialect compilers and Special purpose and system PL/I compilers. Certainly HAL/S, PL/MP, PL/S, PL/8 and SPL/I are special purpose; equally clearly, PL/MP, PL/S and PL/8 are system languages. Shmuel (Seymour J.) Metz Username:Chatul ( talk) 14:10, 25 February 2021 (UTC)
Notes
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)
The article mentions
Series/1 twice; once with a reference and once with the text PL/G Subset for IBM Series/1 Mini Computer with Real Time extensions PL/I Language Reference GC34-0085-0
as a bullet item. I was going to correct the name to PL/I G subset when I realized that
If the text simply refers to the Series/1 PL/I [1] then I will revise it and include the citation. Can anybody clarify this? Thanks. Shmuel (Seymour J.) Metz Username:Chatul ( talk) 15:02, 28 February 2021 (UTC)
References
Prior to this edit, the second sentence of PL/I § Early history said
Business users were moving from Autocoders via COMTRAN to COBOL, while scientific users programmed in General Interpretive Programme (GIP), Fortran, ALGOL, GEORGE, and others.
The edit in question remove the General Interpretive Programme from the list as being an "uncited programming language without notability (no wikipedia page, few Google results, etc.)".
It appears, from some Google search results and from Pilot ACE § Software, that the General Interpretive Programme was originally written for the Pilot ACE and rewritten for the English Electric DEUCE; was it available? on other computers? The page for GEORGE doesn't mention any machine other than the DEUCE, either; was it available on other computers?
Autocoder refers to some IBM assembler languages, and COMTRAN refers to an IBM language that was one of the predecessors to COBOL; IBM may have been a bigger computer company than English Electric, but are those languages worth mentioning here, either?
The only languages mentioned there that don't appear to be specific to particular machines or particular vendors are COBOL, Fortran, and ALGOL (Fortran may have been developed by IBM, but it didn't remain IBM-only). How common were the ACE/DEUCE or even the IBM-only languages relative to COBOL. Fortran and ALGOL? Should those sentences focus on the more commonly used languages? Guy Harris ( talk) 07:22, 4 August 2021 (UTC)
References
Footnote 24 says the list-processing facilities were designed in 1966. The Wikipedia article on Harold (Bud) Lawson says he designed the facility in 1964. I believe the latter is correct and will change it unless proved wrong. Mdmi ( talk) 22:59, 16 November 2021 (UTC)
References
{{
cite book}}
: |work=
ignored (
help)
{{
cite book}}
: |work=
ignored (
help)
Talk:PL/I#Multics PL/I and derivatives claims EPL was a system programming language and a dialect of PL/I that had some capabilities absent in the original PL/I (like varying length strings).
with a citation of
Griswold, Ralph (1978).
"A history of the SNOBOL programming languages" (PDF). ACM SIGPLAN Notices. 13 (8). ACM: 275–308.
doi:
10.1145/960118.808393.
ISSN
0362-1340.
S2CID
5413577. Archived from
the original (PDF) on 2019-03-02., an article that has no connection to either Multics or PL/I, and the claim conflicts with
"Types of Data" (PDF),
NPL Technical Report (PDF), IBM, December 1964, p.
14, 320-0908, String data may be either CHARACTER string or BIT string and may be declared to be either fixed or varying length.
. --
Shmuel (Seymour J.) Metz Username:Chatul (
talk)
00:07, 30 December 2021 (UTC)
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)
Recent changes mention (at least in the edit summary) a connection between threads and tasks. As well as I know, that IBM calls tasks is closer to what many (especially Unix users) call a process. That has the complication what multiprocessing is ambiguous. (What do Unix users call it when they have more than one processor?) An important distinction is the overhead for creating and terminating one. Gah4 ( talk) 09:21, 9 May 2022 (UTC)
fork()
, although anything mapped MAP_PRIVATE
will be copy-on-write (as is now done on UN*Xes) because, to quote the current Single UNIX Specification for fork():
OK, maybe I am thinking of something different. I tend to think of threads as low overhead, and tasks in the OS/360 sense as high overhead, closer to Unix processes. I am not so sure now what Unix says about address space, and especially for fork() vs. vfork(). With threads, you should be able to create a large number of them, where I suspect OS/360 won't let you create hundreds or thousands of tasks. I am also not sure about scheduling of tasks, processes, and threads. Gah4 ( talk) 22:47, 10 May 2022 (UTC)
When programs issue fork() or spawn(), the BPXAS PROC found in SYS1.PROCLIB is used to provide a new address space. For a fork(), the system copies one process, called the parent process , into a new process, called the child process.
To allow the caller to control whether the spawned child process runs in a separate address space from the parent address space or in the same address space, the spawn service allows for the specification of the _BPX_SHAREAS environment variable.
fork()
duplicates the address space, so that subsequent changes to the address space in the parent don't affect the child, and vice versa.vfork()
isn't in the Single UNIX Specification; typically, it "loans" the parent's address space to the child, and temporarily blocks the parent process, with the expectation that the child process will do very little to the writable parts of the address space and will use one of the exec
calls to set up a new address space with a new program. Once it does that, the parent process is unblocked and can continue running, as if it were to modify the address space or any data in the address space, that won't affect the child. The macOS vfork()
man page has two paragraphs of warnings about stuff you should be careful not to do in the child after a vfork()
; those warnings may apply to some other UN*Xes as well. Other UN*Xes might implement vfork()
without the address-space loan, relying on copy-on-write for protection; however, they may still block the parent until an exec
call is done, because the code might implicitly or even explicitly require that the parent not run until the child finishes the setup and the exec
. (I have some memory of a UN*X where vfork()
originally was the same as fork()
, but some stuff using vfork()
broke because the parent ran before the exec
call was done, so the blocking was added. That might have been SunOS 4.0, but it's been so long that I can't be sure.)posix_spawn()
, which is similar to Windows CreateProcess()
in that it creates a child process that is running a new program, and that has some file descriptor/signal/etc. modifications done, but by the kernel rather than by the child process before running the program. No address space copying or loaning need be done there.The article mentions event-driven programming. I suppose that isn't so far off, but isn't what I would have thought about. There are EVENT variables, corresponding to the ECB ( Event Control Block) used by OS/360 and successors. That is mostly used for I/O, but also for task synchronization. For I/O, programs can used double (or more) buffering to keep the I/O system busy, and similarly with asynchronous I/O in PL/I. Gah4 ( talk) 23:38, 10 July 2023 (UTC)
WAIT
and POST
(which some other OSes have, with varying degrees of similarity and generality) would be hidden inside the event loop and in the code that delivers events, respectively.WAIT
statements and assignments to EVENT
variables, but it wouldn't necessarily involve programmers directly using WAIT
statements, for example.The goals for PL/I evolved during the early development of the language. Competitiveness with COBOL's record handling and report writing was required. The language's scope of usefulness grew to include system programming and event-driven programming.
ON
-units as event handlers; the ON
mechanism seems more like a (less-structured) form of
exception handling rather than anything like event-driven programming.
Guy Harris (
talk)
06:42, 11 July 2023 (UTC)
EVENT
variables, and named after the OS/360 ECB. In any case, we also need an article about the
Event Control Block. There are some fun endless channel programs for handling things like terminal I/O. That, and the handling of the I/O interrupt could do it.
Gah4 (
talk)
21:53, 11 July 2023 (UTC)
I thought, as noted above, that it is related to EVENT
variables, and named after the OS/360 ECB.
What is the "it" here? If it's "event-driven programming", I suspect it's unrelated to PL/I EVENT
variables or the OS/360 Event Control Block; I suspect, instead, that the notion of an "event" to which a computer system responds predates all of those terms.
Guy Harris (
talk)
23:12, 11 July 2023 (UTC)
In real-time data processing, events are often independent, not only of the computer, but of each other.
EVENT
"?
Guy Harris (
talk)
02:39, 12 July 2023 (UTC)