Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ames!elroy!jplgodo!wlbr!scgvaxd!ashtate!dbase!csun!psivax!rdlvax!kopaz From: kopaz@rdlvax.UUCP (John Anthony 'Echo' Kopaz) Newsgroups: comp.lang.c Subject: Re: goto's Message-ID: <105@rdlvax.UUCP> Date: Tue, 28-Jul-87 12:33:37 EDT Article-I.D.: rdlvax.105 Posted: Tue Jul 28 12:33:37 1987 Date-Received: Sat, 1-Aug-87 11:08:06 EDT References: <3289@bigburd.PRC.Unisys.COM> <7571@beta.UUCP> <765@haddock.ISC.COM> <960@fmsrl7.UUCP> <7687@mimsy.UUCP> Organization: Research Development Labs (RDL), Culver City, CA. Lines: 79 In-reply-to: chris@mimsy.UUCP's message of 25 Jul 87 04:18:44 GMT Posting-Front-End: GNU Emacs 18.47.1 of Thu Jul 9 1987 on rdlvax (berkeley-unix) in your article you write: >To prove otherwise to yourself, consider any program that contains >at least one `goto' statement. The section of code to which this >branches is either normally reachable, or reachable only by a goto. >(The following may be flawed; I have not bothered to check it >carefully. Nonetheless the general idea ought to be right.) >Case I: Normally reachable. >Replace the beginning of the program with > while not prog_done do >and the end of the program with > if not doing_goto or did_goto then prog_done <- true; fi; > end while; >Now protect every single statement except those which would be >executed by the `goto' with > if not doing_goto then ; fi; >At the beginning of the section performed by the goto, add > if doing_goto then did_goto <- true; fi; >Change the goto statement to > doing_goto <- true; >Add two global variables: > boolean doing_goto <- false, did_goto <- false; >Case II: Not normally reachable. >Move the unreachable code anywhere within the scope of the main >program and protect it with `if not doing_goto then ; fi;'. >The problem has now been reduced to case I. >This can be repeated for all remaining goto statements, using >different variable names for the pair of booleans. -- i don't think all that warped boolean logic is in the best interest to readable code. it has a FORTRAN :~{ flavor to it. in the interest of readability, maintainability, and flexability .... (and a couple 'bilities i may not have mentioned :~)) i think that gotos could be justified. to say otherwise is to limit a ^^^^^^^^ - not are or should be choice in your professional behavior. (that is not very professional.) there are three distinct aspects in program design: data structures, algorythms, and languages. all of which impact on the others. limiting a choice in one will limit choices in the others. another way of looking at it is thus: The Law of Requisite Variety the factor with the most choices will be the dominant (say: controling) factor. 1 choice -> robot 2 choices -> delemma 3+ choices -> FREEDOM!!! this is my opinion, you are not required to agree/disagree, it is just the way i design. tanx. echo. -- john a. kopaz [aka echo.] associate research scientist / software engineer / test specimen voice: 213-410-1244 -- fax: 213-216-5940 -- corporeal: rdl arpa : kopaz@rdlvax.rdl.com 5721 w. slauson ave. uucp : ...!{psivax,csun,sdcrdcf,ttidca}!rdlvax!kopaz culver city, ca 90320