The D Programming Language, labelled blocks

[Richard Harter]

In article <703 at cresswell.quintus.UUCP> ok at quintus.UUCP (Richard A. O'Keefe) writes:
>In article <24935 at cca.CCA.COM>, g-rh at cca.CCA.COM (Richard Harter) writes:
>> Here is an alternative to endif et al.  Use labels to start blocks and
>> 'end labels' to end them....

>He has just re-invented BCPL.

	Er, you give me too much credit.  A feature of BCPL, perhaps,
but not the whole thing> :-)

>Where C has { and }, BCPL had $( and $).
>The name for these was "section brackets".  There was an extra hack:
>"tagged section brackets".  If <id> looked like an identifier,
>$(<id> and $)<id> were tagged section brackets (each was a single token).
>So in BCPL this example would be
>	TEST boolean-expression THEN
>	    $(FOO
>		...
>	    $)FOO
>	ELSE
>	    $(BAR
>		...
>	    $)BAR

>PL/I has a similar feature, one can write
>	label: DO;
>	    statements
>	END label;	/* I may have this wrong */
>There is a difference, though.  In BCPL, the tags on the brackets must
>match exactly, but in PL/I a tagged END may close any number of tagged
>and untagged DOs.
>
>Can anyone who has experience with using this feature suggest why it has
>remained rare.  In particular, does anyone know why it isn't in C, given
>that it was in BCPL?  (Not that I think it's needed.)

As it turns out I do have experience with this exact feature in PL/I.
I once inherited a 40,000 line PL/I program with a 5000 line main program
which used nested tagged begin/end blocks.  I can tell you that multiple
closure is a real disaster.  Fundamentally, the problem is that you can
remove an end statement, thereby changing the block structure of the program,
and the program is still syntactically correct and compiles.  In a large
program which runs across many pages you can't visually confirm that all
the blocks align properly.  It's been a long time now, and I can't recall
the gory details any more.  However the practical effect was the same as
having a C switch construct with some of the terminating case 'break' 
statements unintentionally missing.

As a side point, I like the suggestion that someone made that there be
a fallthrough statement rather than automatic fallthrough.

As to rarity of usage, I suspect the problem is that it is a nice feature
if you use it in a standardized disciplined manner, but that if it is not
obligatory it will be used haphazardly, and that it has no particular value
in that case.   Now that I think on it, you don't need it for small pieces
of code, where everything is clear.  It may have some value for large
programs (as in large number of lines per file).  However my experience
is that the way to deal with the difficulties created by writing large
procedures is not to not write large procedures! :-).

OK, Richard, you win -- D should not have labelled blocks.


-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.