Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: CATCH and THROW
Message-ID: <9009172348.AA19506@ucbvax.Berkeley.EDU>
Date: 17 Sep 90 00:13:22 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 42

> The idea is to have a pointer to the top most catch frame on the return
> stack, and links from catch frame to catch frame.  ...
> when CATCH1 is executed, it builds the catch
> frame, and _calls_ the remainder of its containing routine (instead of
> returning).  When the containing routine returns to the CATCH1 via NEXT,
> CATCH1 simply removes the catch frame and falls into NEXT, too, returning
> from the containing routine.

(Note: The author used the name "CATCH".  I changed it to "CATCH1" for the
purposes of discussion to avoid confusion with the ANS CATCH.)

This mechanism differs from the current ANS CATCH/THROW in the way that it
delimits the section of code that is "guarded" by the catch frame.

In the current ANS approach, the "guarded" code is an entire colon
definition, i.e.:

        ['] FOO CATCH           \ "FOO" is executed under the protection
                                \ of a CATCH frame

In the approach described above, the "guarded" code is the remainder of
the definition which contains the CATCH1 , i.e.:

        : xxx
            ...
            CATCH1
            <guarded code>
        ;

This adds yet another form of "closure" (a fragment of code that constitutes
the body of a control structure) to Forth, as the stuff between CATCH1 and ;
is a closure.

In my opinion, Forth has too many different kinds of closures already.

Also items placed on the return stack before the execution of CATCH1 are
inaccessible to the code following CATCH1 .

Finally, it is unclear whether or not CATCH1 works in interpret state,
due to its unbalanced return stack effect.

Mitch Bradley, wmb@Eng.Sun.COM