Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ucsd!ucbvax!MITCH.ENG.SUN.COM!wmb From: wmb@MITCH.ENG.SUN.COM (Mitch Bradley) Newsgroups: comp.lang.forth Subject: Tagged Catch Message-ID: <9101190337.AA27010@ucbvax.Berkeley.EDU> Date: 18 Jan 91 22:24:53 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Mitch Bradley Organization: The Internet Lines: 38 > : NCATCH ( cfa errno -- errno/0 ) > >R CATCH ( cfa errno -- retcode ) > R> OVER - ( retcode -- retcode errno=retcode ) > OVER AND IF ( retcode flag -- retcode ) > THROW > THEN > ; Since "0 THROW" is a no-op, the above reduces to: : NCATCH ( cfa errno -- errno/0 ) >R CATCH DUP R> - IF THROW THEN ; I think efficiency considerations for this function are down in the noise. > P.S.: Anyway, with the above code we have something similar to SETJMP.H C > library, but not SIGNAL.H. A generic Catch would provide both features in > one. See, SIGNAL.H can be implemented with SETJMP.H... Actually, signal handlers and CATCH/THROW are different things. A signal handler usually executes, does something, and then control returns to where it left off, as though nothing happened. To this end, the system signal handling mechanism has to create a new stack context for the handler, rather than going back to some previously- established context. However, it is sometimes useful to execute THROW from a signal handler, just as C signal handlers sometimes execute longjmp(). To this end, a good Forth signal handling implementation would probably create the "new" stack context on the stack of the task that receives the signal, so if the handler does a THROW, the signal handler stack will be automatically "deallocated". Actually, with the usual implementation of CATCH and THROW, it doesn't really matter where where put the signal handler stack; so long as you have set the user pointer to the right task (a necessity anyway), THROW will put you back in the right place. Mitch