Re: THROW codes and ambiguous conditions

On 31-05-2025 03:10, dxf wrote:

AFAICS the statement in Section 9.3.5
   "A system choosing to execute THROW when detecting one of the ambiguous
   conditions listed in table 9.2 shall use the throw code listed there."
 effectively rules out the traditional use of ABORT" to convey the ambiguous
conditions listed in the table.  Is that how others read it?
 Early on DX-Forth it became apparent that maintaining a list of error
messages accessible by means of a THROW code was going to be messy and
worse - costly.  I wanted CATCH THROW but could do without the vision
ANS appeared to have in mind for it.  The consequence of retaining
ABORT" for classic ambiguous conditions means I can't individually
identify them at CATCH but I've yet to find this a problem.
 I'm curious whether others found ANS' requirement above 'a step too far'?
 

Frankly - I find the standard severely lacking in this regard. They do provide a long table with "errors", but fail to properly define them. All we get is a description, open to interpretation. IMHO - this is not how to set up a standard.
If the condition is described in more detail elsewhere, a basic reference should be listed. Even better - a mnemonic should be attached, not a "hard" code. I mean, even in their freshman years CS students are taught to use enums and constants instead of literals.
But okay - as usual, we do what we can. But I'm *not* gonna include a huge list of non-contiguous messages. Forget it. I got thirty - and that's frankly enough.
3, 4, 5, 6, 9, 10, 12, 13, 19, 22 and 24 are "standard" as far as I'm concerned - and the rest is either missing ("dictionary overflow"? 4tH has no dictionary!) or located elsewhere.
4tH *DOES* provide a list of mnemonics - and I advise to use those in programs rather than ANS THROW codes - if you want to write portable code, that is.
Note that in 4tH there is a compiler on one hand and on the other hand an interpreter - and never the twin shall meet. This also means that most of the codes/messages are specific to the one or the other.
In short, 4tH handles this issue conform its ANS-Forth statement:
"1. 4tH uses a different architecture which makes it impossible to be ANS-Forth compliant, so some constructions are simply not feasible;
2. Some constructions in ANS-Forth are considered to be illogical, inelegant, bloated, not intuitive, error prone, inefficient or otherwise not acceptable."
Hans Bezemer