Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM (Mitch Bradley)
Newsgroups: comp.lang.forth
Subject: Re: ANS TC Magnet for Control, ABORT,QUIT..
Message-ID: <9101031544.AA12910@ucbvax.Berkeley.EDU>
Date: 3 Jan 91 04:35:33 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Mitch Bradley <wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV>
Organization: The Internet
Lines: 72

> I'm surprised they missed this.  I changed the VARIABLE to USER
> when I implemented it a couple of months ago.

We didn't miss it; as detailed in a previous posting, I believe that
CATCH and THROW do NOT need the M attribute.  The fact that the
implementation needs to account for multiprogramming does not imply
that CATCH and THROW have multiprogramming implications from the
application's perspective.

The sample implementation notes that HANDLER should be a USER variable:

    VARIABLE HANDLER  \ Most recent error handler (should be a USER variable)

The example was written this way because the usage of the word USER is
inconsistent among several popular implementations.  Traditionally, USER
was a defining word with interface diagram:

        USER  \ wordname  ( user-area-offset -- )

F83 changed USER to a vocabulary name.  Both variations have problems;
in the sample implementation, I decided to punt and define HANDLER as a
VARIABLE , leaving it to the implementor to read the comment and do the
right thing for the particular system.

> While we're at it; are there any standards around the number
> that is passed to THROW?  I'd like to separate the numbering between
> system and application situations.

Glad you asked that.  That was one of the issues addressed at the
last meeting. Greg Bailey and I worked it out over a plate of spicy
chicken wings, while everybody else was eating lunch at Hardee's.

From BASIS 14, section 14.5:

        Conforming programs may not define values for use with THROW
        in the inclusive range {-1 ... -4095}.  These values are reserved
        for optional system use.

        The values {-1 ... -255} inclusive are reserved for assignment by
        this standard.

        The values {-256 ... -4095} are reserved for implementation defined
        assignments.

        A conforming system may choose to execute THROW when any particular
        ambiguous condition is detected and, if so, must use the value
        assigned that particular condition in the following table:

        Table 14.1. ANS Forth THROW code assignments

                To be determined (within the range -1 ... -255)

        Rationale Note:

                One important use for an error handler is to maintain program
                control under many conditions which ABORT .  This is
                practical only if a range of codes is reserved.  Note that
                an application may overload many standard words in such a
                way as to THROW ambiguous conditions not normally THROWn by
                a particular system (Greg Bailey)

By the way, BASIS 14 changed the term "exception condition" to "ambiguous
condition", reflecting the fact that term was intended to mean that the
standard does not specify precisely what has to happen in one of these
situations.  For example, the standard does not prescribe what an
implementation has to do in case of multiplication overflow.  It could be
silently ignored, or an ABORT might happen, or the process might be
killed (I hope not), the result might wrap around, or max out, or be total
garbage.  The word "exception" was too loaded, because it always seemed
to conjure up visions of a trap or an ABORT happening.

Mitch