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