Re: THROW codes and ambiguous conditions

On 3/06/2025 4:10 pm, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:
...

But how much need today and what's wrong with ABORT"?

 
My guess at the thinking behind the Forth-94 committee's decisions
about that are:
 
1) ABORT" Undefined word" takes more space than -13 AND THROW.  Of
   course, if the system then has a table for translating throw codes
   to messages, that probably eliminates the memory savings, but a
   system that is really tight on memory can just output the error
   code and leave it to the user to look the error up in the manual.
>
2) For CATCH, every ABORT" looks the same, so you cannot do something
   for one kind of error and something else for other kinds.  Of
   course, the question is whether one can do that with the current
   situation (apparently not portably for inaccessible or non-existent
   files in INCLUDED), and whether that's something that Forth
   programmers would make use of if the situation was otherwise.

Perhaps the TC went along with Mitch.  CATCH THROW was his idea and
here's a bunch of codes to go with it.  The extent to which a tiny forth
is going to use ANS is dubious.  Having CATCH THROW just to pass compiler
errors is dubious.  Compilers errors could be handled with ABORT" and two
characters (old-time BASIC users may remember).

   One interesting aspect is that IIRC Mitch Bradley uses
>
   C" <error message>" throw
 
   or somesuch.  If you want to catch that, you have to do it as
   follows:
 
   : printer-on-fire c" printer on fire" ;
 
   : foo ... catch dup printer-on-fire = if ... then ... ;
   : bar ... printer-on-fire throw ... ;
 
   And of course, this only make sense if the system treats an
   uncaught throw as a counted string to be printed.

Couldn't find it in Mitch's github - unless under another name.  He
appears to use C" in a conventional way.