On Tue, Apr 2, 2024 at 1:01 PM Charles H Sauer (he/him) < sauer(a)technologists.com&gt; wrote: call toxic language features--things that impair reliability and maintainability. Good production programming shops ban the use of these features in their code. In the case of PL/I, IMO the most toxic feature is the DEFAULT statement. This is Fortran's IMPLICIT on steroids. The end result of using the DEFAULT statement is that, when you see a variable declaration, you need to review all of the applicable DEFAULT statements to figure out what the variable's attributes are. PL/I was designed to be a successor language to both COBOL and Fortran. One of the ugly features of Fortran is a fussy set of rules on statement ordering, particularly on declaration-type statements. PL/I relaxed those rules. Declarations can appear anywhere in the program and apply throughout the block they appear in. I know of folks who composed programs at the keypunch who used to write down variable declarations on a piece of paper as they came up with them, then when they reached the END statement of the scope block, punched out all the cards for the DECLARE statements. This practice was annoying in that, while reading the code you'd encounter variables that hadn't been declared yet and you'd have to rummage through the code to find the declarations. In the PL/I shops I worked at it was required that all declarations be at the beginning of the scope block. PL/I also has very weak data typing--you can convert almost any data type into almost any other data type. The language has a large and baroque set of conversion rules, and these don't always produce intuitive results, particularly when doing fixed decimal division. It can also mask typos, leading to hard-to-find bugs. I once mistyped: IF A ^= B [I'm using ^ here for the angle-bracket EBCDIC NOT sign character] as: IF A =^ B where A and B were both declared as character strings. So I wrote "if A equals NOT B". The compiler happily generated code to treat B as a character string of 0s and 1s, convert that to a bit string, apply the NOT operation, then similarly convert A to a bit string and do the comparison. This of course caused unexpected program behavior. It might have taken me a long time to find it except that there was a warning diagnostic message from the compiler: "data conversion will be done by subroutine call". This almost always means you've unintentionally mixed data types. -Paul W.

On Wed, Apr 3, 2024 at 1:30 PM segaloco via COFF &lt;coff(a)tuhs.org&gt; wrote: any programming language. Here's another PL/I toxic language feature. Both COBOL and Fortran were designed around the same time that Noam Conmsky was working out formal language theory and both have ill-behaved grammars. Fortran has context-dependent lexical analysis, for example. PL/I is better behaved--the grammar for its lexical analysis is a regular grammar and can be processed with a state machine. But unlike C and other more modern languages, PL/I has no reserved keywords. So you can write things such as: IF IF=THEN THEN THEN = ELSE; Here the first IF and the second THEN are keywords. Everything else is a variable name. Our PL/I shops forbade variable names that were the same as language keywords. I suppose the designers of the PL/I language wanted to allow for the introduction of new language keywords while retaining backwards compatibility with programs that may have used the new keyword sa a variable name. -Paul W.

On Wed, Apr 3, 2024 at 11:37 PM Wesley Parish &lt;wobblygong(a)gmail.com&gt; wrote: in. Local declarations always appeared immediately following the PROCEDURE or BEGIN statement that starts the scope to which the declaration applies. PL/I adopted the idea of nested scopes from Algol. One other programming convention we used was to keep variable scopes as localized as possible. Among other things, it makes lifetime analysis easier for the compiler. Another feature present in PL/I but not in C or most other languages is nested procedures. A nested procedure inherits all of the variables accessible in the scope of the containing procedure in which it's declared. Up-level addressing (use of variables declared outside the nested procedure) is somewhat error prone and less efficient than accessing data via a parameter. PL/I also supports recursion, something not provided for in the usual IBM S/360 ABI calling convention. A procedure that can be called recursively must be declared with the RECURSIVE attribute. Unlike C, in IBM S/360/370 PL/I recursion was disallowed by default. DEC's ABI for VMS supports recursion by default and so DEC PL/I dropped the RECURSIVE attribute. PL/I also supports an extended version of Fortran's computed GOTO via label variables. PL/I statements are labeled by name as opposed to Fortran's statement numbers. A label variable can be assigned a statement label value and a GOTO statement using the label variable transfers control to whichever statement label is held in the label variable. Label variables encourage rat's nest programming styles and very much went out of fashion when structured programming came along. -Paul W.

On Tue, 2 Apr 2024, Charles H Sauer (he/him) wrote: [...] Gadzooks... For our "write a simple compiler" assignment I threatened to use SNOBOL, but my lecturer (Ken Robinson) threatened to fail me :-) -- Dave

On 2024-04-07 19:25, Charles H Sauer (he/him) wrote (in part): I recall a job cards lying around the card readers with ICEBOL written on them. This may have been a local Toronto variant (in the 1970s). S.

On Tue, 9 Apr 2024, William H. Mitchell wrote: Ahh... SPITBOL... We used it at UNSW, but it came with a time bomb i.e. the licence had to be renewed every so often. So, me being me I took a hex dump and patched the expiry date with Superzap. Well, it sort of worked... The compiler would then crash at random for no apparent reason, so I took a closer look; it turned out that there was more than one check on the expiry date, and took a jump to whatever random "address" was in R0 (I think). OK then; playing silly games are we? I wrote a program that LOADed SPITBOL into memory, and scanned it for anything that looked like that expiry date, and printing them (nicely formatted, of course). After checking the context there were about a dozen of them, and I patched the lot; it worked fine after that... For that effort Dr. Graham McMahon (another of my CompSci lecturers) gave me the "Superzap of the Year" award :-) -- Dave

On 2024-04-02 12:40, Clem Cole wrote (in part): A scanned printout (in assembler) is available, if someone is brave enough. S.