home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.arch
- Path: sparky!uunet!haven.umd.edu!purdue!yuma!csn!raven!rcd
- From: rcd@raven.eklektix.com (Dick Dunn)
- Subject: Re: A challenge to the anti-goto
- Message-ID: <1992Nov8.065551@eklektix.com>
- Organization: eklektix - Boulder, Colorado
- References: <Bx0BuG.s4@mentor.cc.purdue.edu> <1cvoctINNmhs@agate.berkeley.edu> <1992Nov5.145032.6678@sei.cmu.edu>
- Date: Sun, 8 Nov 1992 06:55:51 GMT
- Lines: 39
-
- firth@sei.cmu.edu (Robert Firth) writes:
- >jhauser@pine.CS.Berkeley.EDU (John Hauser) writes:
- >> If we've known about this problem for twenty years, why don't we
- >> have more powerful `break' instructions in our existing languages??
- >
- >We do. Exactly the construct you require is found in Ada...
- ...
- >My question: if we have had the *solution* to this problem for ten years,
- >why don't more people know about it and use it?
-
- The "solution" predates Ada by quite a bit, of course...
-
- The reason we don't see it more often is that it's turned out not to be
- as good an idea as people think when they first consider it.
-
- Single-level "break" can make some pieces of code a lot easier to read.
- It's simple, useful, and straightforward.
-
- Multi-level "break" is still useful, but because it can reach further out,
- it has several practical disadvantages:
- - It requires some sort of labeling, to identify how far out (how
- many levels) you're exiting...this gives it a little of the
- flavor of a goto.
- - In general it takes you "farther" out in the code--the transfer
- of control will on the average be more distant, hence generally
- harder to follow.
- - It destroys a certain sense of "nesting"--control from within
- one or more inner structures can reach various outer points.
- All of these reasons taken together still wouldn't condemn the idea of a
- multi-level break if it were useful enough. But it turns out to be one of
- those 90% situations--single-level break covers 90% of the need, and the
- remaining 10% doesn't justify the added complexity of another construct.
-
- Therefore, most languages have omitted it. It's not that it wouldn't be
- useful, but only the consensus is that it isn't useful enough to justify
- the added baggage in the language.
- --
- Dick Dunn rcd@raven.eklektix.com -or- raven!rcd Boulder, Colorado
- ...Simpler is better.
-