The point is that signal does both more and less than a PL/I goto and maximally violates the law of least astonishment. It's one of the pitfalls I warn about in my Safe REXX papers.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Paul Gilmartin <[email protected]> Sent: Friday, January 11, 2019 4:21 PM To: [email protected] Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue) On Fri, 11 Jan 2019 20:58:51 +0000, Seymour J Metz wrote: >FSVO goto that lives in a different universe from PL/I. The REXX signal >statement trashes the stack rather than simply popping it appropriately. >Consider > SIGNAL trashes the DO nest but it does not update the CALL/RETURN stack. I encountered this to my dismay working with code of a co-worker who relied on SIGNAL to exit a funtion by branching to the top of a DO on an error condition. Worked when he tested it; overflowed CALL/RETURN stack on a large production data set. Rexx sorely lacks LONGJUMP for this purpose. (An extension to ITERATE/LEAVE would suffice and be better structured.) >do I=1 to n > do j=1 to m > ... > if foo then signal bar > ... > end > ... > bar: > ... > end Rather, I'd propose: do I=1 to n do j=1 to m ... call F ... end j /* I label ENDs whenever possible. */ ... bar: ... end I return F: procedure expose I ... if foo then iterate I ... return --gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
