Deutsch   English   Français   Italiano  
<nnd$5d07338c$61b87fbd@d4d89ef8da41e19e>

View for Bookmarking (what is this?)
Look up another Usenet article

Date: Sun, 1 Jun 2025 19:44:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: THROW codes and ambiguous conditions
Newsgroups: comp.lang.forth
References: <f827ba6fc80427f3ce0317835bd8ae47a4445e07@i2pn2.org>
Content-Language: en-US
From: Hans Bezemer <the.beez.speaks@gmail.com>
In-Reply-To: <f827ba6fc80427f3ce0317835bd8ae47a4445e07@i2pn2.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <nnd$5d07338c$61b87fbd@d4d89ef8da41e19e>
Organization: KPN B.V.
Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!2.eu.feeder.erje.net!feeder.erje.net!feed.abavia.com!abe007.abavia.com!abp001.abavia.com!news.kpn.nl!not-for-mail
Lines: 55
Injection-Date: Sun, 01 Jun 2025 19:44:57 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"

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