Xref: utzoo comp.lang.misc:1466 comp.lang.c:9479 Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc,comp.lang.c Subject: Re: Block Closure Message-ID: <757@l.cc.purdue.edu> Date: 19 Apr 88 21:17:07 GMT References: <2853@enea.se> <2400014@otter.hple.hp.com> <918@rlgvax.UUCP> Organization: Purdue University Statistics Department Lines: 59 Summary: A new idea, possibly useful In article , gaynor@porthos.rutgers.edu (Silver) writes: > firth@sei.cmu.edu (Robert Firth) writes: > > It seems clearly desirable that every control construct be able to > > contain multiple statements, embedded within clear starting and > > ending delimiters. > > I find these delimiters an annoying eyesore at best. I usually write > algorithms without them, using indentation show heirarchy. I only > include them in fulfillment of a target language's definition. In > fact, there are languages whose heirarchical structure is determined > solely by indentation (the only one that comes to mind is > josh@rutgers.edu's CAML, still under development). > > Regards, > [Ag] I find both of these methods at times easy to follow, and at times hard to follow. There is also the problem of a multiple break. If we use indentation, there is the problem of following the indentation 20 or 50 or 100 lines; in addition, this greatly limits the number of hierarchical levels. Admittedly 10 levels are already difficult to read, but with indentation lines also get shorter. One may also want to use some form of indentation within blocks to inprove readability. The problem with if...fi, case...esac, do...od etc. is that there may be several pending; which is now ended? I hereby make a proposal which I believe may treat the problem in a better manner. First, I am willing to have unlabelled blocks with appropriate delimiters such as the above pairs and also with {...}. (It is my under- standing that if the latter is used that the reversed name does not have to be used also.) I suggest that labelled blocks also be allowed, with possible notations as LABEL{ ... }LABEL if(....) LABEL:: end LABEL; Also if a break is desired which goes back several levels, this could be indicated as break LABEL and another useful "gadget" might be endall LABEL which would close all blocks since LABEL was invoked. This is a suggestion for the introduction of labelled blocks. In no way do I claim that this is necessarily the best way to do it, nor do I believe that I have found all of the uses for labelled blocks. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet