Path: utzoo!attcan!uunet!willett!dwp
From: dwp@willett.UUCP (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: NUMBER and block files and ANS Forth
Message-ID: <1266.UUL1.3#5129@willett.UUCP>
Date: 3 Jul 90 03:02:23 GMT
References: <9007020308.AA02478@ucbvax.Berkeley.EDU>
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 52

wmb@MITCH.ENG.SUN.COM, in <9007020308.AA02478@ucbvax.Berkeley.EDU>, writes:

> If you have CATCH and THROW , the obvious implementation of ABORT is
> "-1 THROW".  This turns out to be an excellently useful thing, because
> then a program has the option of handling any ABORT condition that arises.
> 
> An even better approach is to let the application take care of
> CATCH'ing the call to NUMBER, because that gives the application
> the flexibility of choosing the level at which to handle the error
> (which might be several levels up from the actual call to NUMBER ).
> This can eliminate several levels of "passing flags back up".

The problem with letting things THROW several levels up, is in
determining what error condition you are CATCHing.  Without named
CATCH/THROW tags how could you know?  A generic abort isn't really all
that useful unless you are careful to catch close enough around anything
you care about so that nothing else accidently sets off that CATCHer.  I
suspect that that just can't work because you never really know what the
CATCH protected word might end up invoking.  I suspect that you also
need to put a generic "some bad thing happened somewhere" CATCHer in the
top level word of your application, but even then recovery is somewhat
problematic when you don't know what you're recovering from.

> One other observation:  Implementing ABORT with CATCH and THROW
> eliminates the one "unavoidable" forward reference in the Forth kernel
> (the ABORT - QUIT - INTERPRET - NUMBER - ABORT cycle).  A kernel with
> CATCH and THROW can be compiled entirely incrementally.

This says to me that there is something fundamentally "right" about
CATCH/THROW.  That there is a new "factoring" in the kernel which is
technically superiour to the old "factoring".  I haven't personally
written enough Forth code of any kind to assess the practicalities of
this "improvement."  My experience with other languages says it works
well, but that makes me less inclined to trust that experience.

I'm curious to know (if you follow-up to this question perhaps a
change of Subject line is in order) how various implementers have
"evolved" their kernels in order to make them simplier and easier to
meta-compile.  This is a very general question.  I would be curious to
look at the overall structures of various Forth kernels to see if
"independant" evolution arrived at some small number of techniques.
I'm not talking "(in)direct-threaded vs. subroutine" but the way in
which the particular Forth's "core" word set is organized.  (Not that
I particularly have the copious spare time, nor the analytically skills
to extract that kind of information from FORTH code...)

-Doug


---
Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp
Daily: ...!{uunet,nfsun}!willett!dwp   [in a pinch: dwp@vega.fac.cs.cmu.edu]