Re: THROW codes and ambiguous conditions

dxf <dxforth@gmail.com> writes:

In the early days of microcomputing memory was severely limited and error codes
were used to save space.

And for many in the Forth community these times are not over.  They
argue with embedded systems, with retro systems such as an 8086 Forth,
with Chuck Moore quotes or with 10x 100x 1000x ... efficiency (ok,
that was Jeff Fox's specialty), and denounce everything that they
dislike as consuming too much memory.

Of course, when there is something they like and that consumes memory,
or something that they dislike and that reduces memory consumption,
they do not apply any of these considerations.

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.
  
   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.

I don't use forth for scripting which might require sending codes and can't think
of an app where I've used codes.

Actually, there's a pitfall there:

In Unix, the exit code is an 8-bit unsigned value, and 0 means
success.  At one point, deelopment Gforth in scripting mode just used
the throw code as exit code; its low 8 bits became the actual exit
code, so "256 throw" appeared to be a success.  Currently, throw codes
1..255 are used as exit codes, and all other uncaught non-zero THROWs
in scripting mode result in exit code 1.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/