• Re: THROW codes and ambiguous conditions

    From albert@albert@spenarnc.xs4all.nl to comp.lang.forth on Mon Jun 9 12:49:10 2025
    From Newsgroup: comp.lang.forth

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

    Groetjes Albert
    --
    Temu exploits Christians: (Disclaimer, only 10 apostles)
    Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
    Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
    And Gifts For Friends Family And Colleagues.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From dxf@dxforth@gmail.com to comp.lang.forth on Mon Jun 9 21:36:40 2025
    From Newsgroup: comp.lang.forth

    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' :)

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From zbigniew2011@zbigniew2011@gmail.com (LIT) to comp.lang.forth on Mon Jun 9 12:24:22 2025
    From Newsgroup: comp.lang.forth

    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' :)

    You may want to try this one:
    https://www.forth.org/fig86new.zip
    This is the one I'm tinkering with (just presently
    I already heavily modified it) and its loops are
    pretty standard, I believe (it's from 1982).

    It started few years ago, when I was curious could
    I make it assemble using MASM (it didn't want to...),
    because it was prepared using some 'exotic' one, no
    more available.

    --
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Paul Rubin@no.email@nospam.invalid to comp.lang.forth on Tue Jun 10 14:11:30 2025
    From Newsgroup: comp.lang.forth

    albert@spenarnc.xs4all.nl writes:
    Probably there is, revectoring EMIT and forcing the Forth to work
    with single characters. Anton Ertl can show how it is done with
    gforth.

    Yes, but it seems to be implementation specific. Reasonable point about
    <#... being in CORE. It always seemed to me that those words should
    have been in an extension.
    --- Synchronet 3.21a-Linux NewsLink 1.2