Implicit conversion is always problematical; you're damned if you do and damned if you don't. The tradeoff in PL/I was in favor of expressive power, and I sort of agree, although experience with Ada has given me an appreciation of strict typing.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Bernd Oppolzer <bernd.oppol...@t-online.de> Sent: Wednesday, July 17, 2019 5:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND Parameter) Am 17.07.2019 um 19:54 schrieb Paul Gilmartin: > On Wed, 17 Jul 2019 12:22:35 -0400, Steve Smith wrote: > >> The original sin was making "=" the assignment operator. I guess we can >> blame that on FORTRAN, and it must make mathematicians cringe still. >> > I once (ca. 1967) needed to enlighten and disillusion a naive > but persistent physics graduate student who had coded in what > he believed was FORTRAN something akin to: > > B( 1 ) = X( 1 ) * 1 + X( 2 ) * 2 > B( 2 ) = X( 1 ) * 3 + X( 2 ) * 4 > > B( 1 ) = 3.14 > B( 2 ) = 2.718 > > PRINT X( 1 ) X( 2 ) > ... > expecting to solve a system of linear equations, apparently assuming > that "=" was not assignment but a sort of identity declaration. I.e. > determine the values of X() that satisfy all the "equations". I can > barely imagine the number of false starts he needed to circumvent > syntax errors before he approached me for counsel. > > -- gil > This reminds me of a similar story :-) I wrote a PL/1 parser for a customer of mine some years ago; the idea was to detect some logic errors and flag some language constructs which the customer did not want (not allowed by site standards); and to issue warnings on some constructs which the compiler at that time couldn't. There were several thousand sources to be checked, because it was a large company. About 10 percent of the programs had some sort of issue. One program had a coding like this: IF 9 < ZZ < 20 THEN DO; ... this was flagged by my parser; it complained because a BIT value (9 < ZZ) is compared with a numeric value (20). The PL/1 compiler didn't say anything, no error or warning. Obviously this is not what the coder intended; the coder must have had a mathematics background. He (or she) apparently asked for IF (9 < ZZ) & (ZZ < 20) THEN DO; ... The original coding is always TRUE, BTW. ('0'B and '1'B are both < 20). This error has not been detected for more than 20 years :-) and IMHO in this case again the problem is the PL/1 language definition, because it allows all these implicit type conversions, even very strange ones. Kind regards Bernd ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
