🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #5456

Re: Block Closure

#5456
From: Herman Rubin
Date: Tue, 19 Apr 1988 21:17
59 lines
2914 bytes
In article <Apr.18.19.01.07.1988.13299@porthos.rutgers.edu>, 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
Technical Details
Message-ID: <757@l.cc.purdue.edu>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
References: <2853@enea.se> <2400014@otter.hple.hp.com> <918@rlgvax.UUCP> <Apr.18.19.01.07.1988.13299@porthos.rutgers.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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> <Apr.18.19.01.07.1988.13299@porthos.rutgers.edu>
Organization: Purdue University Statistics Department
Lines: 59
Summary: A new idea, possibly useful