Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: Named Blocks (Was Re: Oh noooooo!!)
Message-ID: <2055@munnari.oz.au>
Date: 8 Sep 89 03:24:08 GMT
References: <7598@goofy.megatest.UUCP> <475@thirdi.UUCP> <297@crdos1.crd.ge.COM>
Sender: news@cs.mu.oz.au
Lines: 30

In article <475@thirdi.UUCP>, peter@thirdi.UUCP (Peter Rowell) writes:
|  One thing I would have loved to have seen introduced by ANSI would have
|  been "named blocks", but I am sure that parsing them is a bitch.
In article <297@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:
>  I think the idea of naming the loop rather than the block, as
>  suggested earlier, would be easier to parse.

I would point out that BCPL had named brackets $(NAMEHERE ..... $)NAMEHERE
long before C was thought of, and that the BCPL code for the front end of
the BCPL compiler is available in the book on BCPL.  Far from being
"a bitch" to parse, they are dead simple.  Just treat all brackets as
named with a possibly empty name, push the name onto a stack whenever you
see a "{...", and whenever you see a "}..." check for a match with the
top of the stack.

We can't use '{' "string" in an extension to C, because a C statement may
begin with a string.  For example
	"abc"[i] == ch ? foo() : baz();
Since C statements can't start with colons, perhaps
	<opening brace> ::= '{' ':' <identifier> | '{'
	<closing brace> ::= '}' ':' <identifier> | '}'
might do.

PL/I has named brackets where a labelled END statement may stand in for
any number of anonymous END statements as well; this is widely regarded
as a mistake.  Ada has loop labels (label:loop) and statement labels as
well (<<label>> statement).  

All things considered, might we not be better off with compilers that
can generate in-line code for nominated functions?