Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!cca!g-rh
From: g-rh@cca.UUCP (Richard Harter)
Newsgroups: net.lang
Subject: Escape structures (retitled)
Message-ID: <7040@cca.UUCP>
Date: Sun, 6-Apr-86 18:00:45 EST
Article-I.D.: cca.7040
Posted: Sun Apr  6 18:00:45 1986
Date-Received: Wed, 9-Apr-86 22:12:33 EST
References: <1187@mmintl.UUCP> <6925@cca.UUCP> <>
Reply-To: g-rh@cca.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge
Lines: 76
Summary: 

Summary: I proposed a language consisting of labelled blocks (or
loops) with an escape statement that left the labelled block via
a labelled 'fragment' of code.  It has been mentioned to me in
correspondence that the PL/I condition handler can be used in this
fashion.

In article <> savage@ssc-vax.UUCP (Lowell Savage) writes:
>....
>I beleve that Ada provides such a facility (with an "exit" statement
>which can take arguments that are block names) only without the
>FRAGMENT capability.  If there is some set of code that needs to be
>executed before the block is exited, then that code can come before
>the exit statement.  However, Ada also provides another mechanism
>which I think can be used for complete purpose intended by Richard.
>This is the exception mechanism.  The FRAGMENT is now the statements
>after the exception handler, and the "exit" or "escape" statement is
>now the Ada "RAISE" statement which raises some exception known only
>within that block of code.
>
	I knew (having written PL/I code for several years) about PL/I
ON conditions, but I am not acquainted with the similar mechanism in
ADA.  It sounds like the PL/I and Ada constructs are more or less
functionally equivalent to what I was suggesting, but not quite.
The question is, what happens to control after the exception handler
is done.  In PL/I it goes back to the point where the exception was
raised -- the escape is handled separately with a goto.  Thus:

	......
	if (problem) then raise(exception)
	......
LBL:

	......
exception_handler:
	......
	goto LBL

This is probably necessary for exception handlers which typically
either (a) fixup the problem and go back to where it came from or
(b) wrench control from the normal control stack and skip up multiple
levels, hopefully disposing of accumulated frames along the way.

	If I understand what Ada offers correctly, one has either
the automatic block exit or the fragment (handler) but not both at
the same time.  I could (but wont) dig up my Ada books and check it
out.

	Some more thoughts that occur to me in passing.  The first is
that I am not a fan of using labels to indicate the first statement
after a block of code, which all GOTO based solutions end up using;
I would prefer to have blocks labelled and have escape statements
which leave the block.  This is in direct analogy with 'return'
statements from procedures; I can escape from any level of nesting
within a procedure with a return statement -- I ought to be able
to do the same thing with internally nested blocks.  Come to think
of it, the BLOCK construct I was proposing is similar to a nested
procedure except that:

(a)	It is executed by falling through to it;
(b)	It is not invoked by name;
(c)	It is parameterless.

[Here is a construct that gives me the willies when I think about it:
a return statement that lets you specify what routine you are returning
from!  An escape statement that lets you escape from a block at a
higher level than the one you are in does this, but the legitmacy of
the escape can be checked at compile time.]

	Another thought is that the whole problem of exception
handling is a mess.  C's setjmp/longjmp mechanism is no more than
a "here is a low level primitive for the job -- you figure out
how to do it yourself" approach.  The PL/I ON condition handlers
are only a small cut above C.  It seems to me that the whole area
of error handling is in need of major theoretical analysis.

		Richard Harter, SMDS Inc.