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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <0000000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Friday, January 11, 2019 4:21 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 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
