Re: THROW codes and ambiguous conditions

On 9/06/2025 8:49 pm, albert@spenarnc.xs4all.nl wrote:

In article <15f0ff69ffcb0b25a08cace9d19b8b8522a828b1@i2pn2.org>,
dxf  <dxforth@gmail.com> wrote:

On 8/06/2025 9:51 pm, albert@spenarnc.xs4all.nl wrote:

In article <2025Jun8.095626@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

albert@spenarnc.xs4all.nl writes:

>
It is occasionally useful to have conversions to a string that
not immediately prints. Even figforth had a (D.R) that was a
D.R without the type.

>
It's not in the fig-Forth Installation Manual / Glossary / Model Release !
>
http://wiki.yak.net/1089/fig-FORTH_Manuals_May79.pdf
>
nor in the source code.
>
https://raw.githubusercontent.com/ForthHub/FIG-Forth/refs/heads/master/fig.fth

>
I should have known better.
https://home.hccnet.nl/a.w.m.van.der.horst/figdoc.zip
I remembered the way D. was reduced in the code to
D.R and confused the two mechanisms.

>
It's probably easier to justify (D.) than (D.R).  If one needs to right-justify
numbers, chances are one will need to right-justify non-numeric strings as well.
For this reason I have S.R in the kernel and (S.R) as a library function.
>

 
(D.) is a good addition to a kernel. In 2023 it was added to ciforth's kernel.
This honour is bestowed on less than half a dozen words since 2002 version 4.0.,
demonstrating that fig-forth was nearly perfect. Other words are NIP and $\ .

Tried to load LIT's Roman code into FigForth for CP/M only to find it used
non-Fig words NIP 2DROP TUCK 1- .  I also needed something akin to S" to pass
the numeric string to the routine.  All edits had to done externally as no
editor was present.  After fixing all that the routine still didn't work
properly.  It appears LIT's code relies on a non-symmetric DO LOOP - which is
not FigForth standard.  Let's just say I won't be returning to FigForth any
time soon.  Once in a decade is enough to remind me 'Never again' :)