Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #134559 > unrolled thread

Recognizer proposal

Back to article view | Back to comp.lang.forth

Contents

  Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-09 07:49 +0000
    Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-10 13:36 +0100
      Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-10 17:48 +0000
        Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-11 11:21 +1100
          Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 09:05 +0000
            Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-11 12:46 +0100
            Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 13:36 +0100
              Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 20:49 +0000
            Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-11 18:37 +0000
              Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 12:25 +0100
          Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 14:34 +0100
            Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-12 11:35 +1100
              Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 07:24 +0000
                Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-12 10:59 +0100
                  Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 10:13 +0000
                    Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 13:22 +0100
                  Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 13:07 +0100
                Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-12 20:59 +1100
              Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 12:35 +0100
                Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 13:30 +0100
                  Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 13:44 +0100
            Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 07:35 +0000
              Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-12 10:55 +0100
                Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-13 08:27 +0000
                  Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 13:43 +0100
                    Re: Recognizer proposal Gerry Jackson <do-not-use@swldwa.uk> - 2026-02-13 23:50 +0000
                      Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-14 12:53 +1100
                        Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-15 13:33 +0100
                          Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-16 12:18 +1100
                        Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-19 13:42 +0100
                          Evolution of Forths  was Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-19 14:38 +0100
                            Re: Evolution of Forths was Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-20 12:33 +1100
                              Re: Evolution of Forths was Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-20 11:58 +0100
                                Re: Evolution of Forths was Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-24 10:45 +1100
                              Re: Evolution of Forths was Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-21 16:35 +0100
                                Re: Evolution of Forths was Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-24 13:13 +1100
            Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-02-25 20:25 -0800
              Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-26 06:53 +0000
              Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-26 13:09 +0100
                Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-27 20:24 +1100
                Re: Recognizer proposal Gerry Jackson <do-not-use@swldwa.uk> - 2026-02-27 09:25 +0000
                  Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-27 14:48 +0000
                Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-27 19:21 +0100
                  Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-28 10:15 +1100
                  Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-28 15:34 +0100
                    Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-28 17:56 +0100
                    Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-02-28 22:45 -0800
                      Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-01 07:54 +0000
                        Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-03-01 14:17 -0800
                          Re: Recognizer proposal antispam@fricas.org (Waldek Hebisch) - 2026-03-02 00:21 +0000
                            Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-02 12:36 +0100
                              Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-03-04 16:48 -0800
                        Re: Recognizer proposal antispam@fricas.org (Waldek Hebisch) - 2026-03-02 00:17 +0000
              Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-26 07:32 -0600
              Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-03-02 13:23 +0000
                Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-03 13:47 +0100
                  Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-03-03 14:39 +0000
                    Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-03-04 16:52 -0800
                      Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-03-06 10:54 +0000
                      Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-06 12:22 +0100
                    Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-03-07 17:58 +0100
                Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-03-03 18:33 +0100
        Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 13:54 +0100
          Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 13:09 +0000
            Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 15:59 +0100
              Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 20:46 +0000
          Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-11 16:30 +0000
            Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-12 12:07 +0100
              Re: Recognizer proposal Lars Brinkhoff <lars.spam@nocrew.org> - 2026-02-12 13:00 +0000
              Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 12:55 +0000
                Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 14:17 +0100
              Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 13:28 +0100
                Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-14 01:23 +1100
              Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-16 22:07 -0600
                Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-17 21:25 +1100
                  Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-17 08:16 -0600
                    Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 15:32 +0000
                Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-02-17 14:13 +0000
                  Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-17 20:21 +0100
                  Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-18 13:08 +1100
      Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-11 12:29 +0100
    Re: Recognizer proposal minforth <minforth@gmx.net> - 2026-02-18 11:14 +0100
      Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 15:40 +0000
        Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-24 02:43 -0600
          Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-08 18:15 -0500
            Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-09 07:49 +0000
              Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-09 10:37 +0100
                Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-10 07:35 +0000
                  Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-10 12:06 +0100
                    Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-11 09:48 -0500
              Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-09 16:48 -0500
                Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-11 09:45 -0500
    Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-18 12:33 +0100
      Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 15:48 +0000
        Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-25 14:11 +0100
    Re: Recognizer proposal NN <november.nihal@gmail.com> - 2026-03-19 19:23 +0000
      Re: Recognizer proposal thresh3@fastmail.com (Lev) - 2026-03-19 23:13 +0000

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#134594

In article <nnd$11632ec1$4065bb35@f854684003bd1681>,
Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
<SNIP>
>
>When I designed 4tH, I got rid of double numbers (and consequently,
>mixed numbers as well). Yeah, they have their use in the 16 bit era -
>but not anymore. FYI - that was 1994.
>
>In the 64-bit era, I think we could get rid of double numbers
>altogether. Dump the whole thing in a separate wordset and be done with
>it. Clean up CORE.
>
>"Yeah, but don't you know how much code would get broken?" Yeah, I've
>heard that song before. Let's keep dragging all that old stuff along
>till eternity. You can never have enough technical depth, can you.
>
>What about a wordset "OBSOLETE", where we can dump all that stuff. Like
>WORD, QUERY, EXPECT, CONVERT? So people can still compile their old
>stuff without lifting a finger?

ciforth (meaning i.a. close to iso forth) avoids all deviations from
the standard, at the expense of conciseness and elegance.
That goes a long way to running most portable programs.
One example of a deviation is the mapping of Linux exception numbers
to supposedly portable numbers. I use the exception numbers itself.

>
>Hans Bezemer
>
Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#134578

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>Extending the functionality of already defined words (in previous 
>wordsets) was always a weak point of ANS-94. I don't know if other 
>language standards use this, but I don't feel comfortable with 
>"redefining" or "extending" words.

Most other standards don't try to cater to small implementations as
much as the Forth standard does.  It's pretty pointless, though: Big
implementations implement almost everything, and small implementations
pick and choose from the standard requirements anyway, even among the
requirements for CORE words.  The CORE wordset has only been a
goalpost for peoplle who implement Forth as an exercise.

>I still think that meddling with the text interpreter is a big no-no and 
>an invitation to disaster. Never leave to a computer that which a 
>programmer can signify as his intent.

Recognizers provide additional ways for programmers to signify as
their intent.

- 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 2025 proceedings: http://www.euroforth.org/ef25/papers/

[toc] | [prev] | [next] | [standalone]

#134579

On 12-02-2026 08:35, Anton Ertl wrote:
> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>> Extending the functionality of already defined words (in previous
>> wordsets) was always a weak point of ANS-94. I don't know if other
>> language standards use this, but I don't feel comfortable with
>> "redefining" or "extending" words.
> 
> Most other standards don't try to cater to small implementations as
> much as the Forth standard does.  It's pretty pointless, though: Big
> implementations implement almost everything, and small implementations
> pick and choose from the standard requirements anyway, even among the
> requirements for CORE words.  The CORE wordset has only been a
> goalpost for peoplle who implement Forth as an exercise.
> 
>> I still think that meddling with the text interpreter is a big no-no and
>> an invitation to disaster. Never leave to a computer that which a
>> programmer can signify as his intent.
> 
> Recognizers provide additional ways for programmers to signify as
> their intent.
> 
> - anton

I don't think that people who are "implementing Forth as an exercise" 
can be bothered to make it "a standard compiler". So I don't see a true 
argument here.

And although wordsets build modularity (which I welcome) it becomes 
useless when it requires you to patch wordsets already implemented. I 
mean - that it depends on other wordsets, I think that's unavoidable. 
But patching those wordsets? That's just bad engineering.

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#134586

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>On 12-02-2026 08:35, Anton Ertl wrote:
>> [...] small implementations
>> pick and choose from the standard requirements anyway, even among the
>> requirements for CORE words.  The CORE wordset has only been a
>> goalpost for peoplle who implement Forth as an exercise.
...
>I don't think that people who are "implementing Forth as an exercise" 
>can be bothered to make it "a standard compiler".

The point is not standard conformance, but a goalpost: To have
something to direct the work, and also to have something that tells
the implementor when the project is complete.

>And although wordsets build modularity (which I welcome) it becomes 
>useless when it requires you to patch wordsets already implemented.

Who is "you" in this sentence?  Given that you write "implemented",
you seem to argue that the standard requires the system implementor to
implement the base word, and then to patch it.  This is not the case.
The system implementor who has decided to implement the FILE words in
addition to the CORE words can implement the FILE version of S" from
the start, without any patching.

Note also that the FILE version of S" conforms to the requirements for
the CORE version of S", and that's generally the case for the extended
versions of words.  E.g., the specification of CORE's POSTPONE
includes

| An ambiguous condition exists if name is not found.

so it does not specify what "POSTPONE 123" means.  The proposed
recognizer version of POSTPONE specifies that.

- 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 2025 proceedings: http://www.euroforth.org/ef25/papers/

[toc] | [prev] | [next] | [standalone]

#134593

On 13-02-2026 09:27, Anton Ertl wrote:
> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>> On 12-02-2026 08:35, Anton Ertl wrote:
>>> [...] small implementations
>>> pick and choose from the standard requirements anyway, even among the
>>> requirements for CORE words.  The CORE wordset has only been a
>>> goalpost for peoplle who implement Forth as an exercise.
> ...
>> I don't think that people who are "implementing Forth as an exercise"
>> can be bothered to make it "a standard compiler".
> 
> The point is not standard conformance, but a goalpost: To have
> something to direct the work, and also to have something that tells
> the implementor when the project is complete.
> 
>> And although wordsets build modularity (which I welcome) it becomes
>> useless when it requires you to patch wordsets already implemented.
> 
> Who is "you" in this sentence?  Given that you write "implemented",
> you seem to argue that the standard requires the system implementor to
> implement the base word, and then to patch it.  This is not the case.
> The system implementor who has decided to implement the FILE words in
> addition to the CORE words can implement the FILE version of S" from
> the start, without any patching.
> 
> Note also that the FILE version of S" conforms to the requirements for
> the CORE version of S", and that's generally the case for the extended
> versions of words.  E.g., the specification of CORE's POSTPONE
> includes
> 
> | An ambiguous condition exists if name is not found.
> 
> so it does not specify what "POSTPONE 123" means.  The proposed
> recognizer version of POSTPONE specifies that.
> 
> - anton

I could have used "one" - wouldn't have changed the meaning. Nice 
"Whataboutism"! The argument was (and is) what use has a standard for a 
toy compiler? Things are done when "one" says they're done. You (like 
"Anton") overestimate the authority of a standards body greatly. 
Especially when the language concerned is almost dead. There are more 
people implementing that compiler than writing programs for it!

And yes - it often happens (I speak from my own experience) that "one" 
(now clear for you? :) thinks - "that's as far as I want/need to go" and 
consider otherwise later. And yeah, then "one" has to patch it. Because 
the word *IS* already defined "one" has to extend its functionality.

"An ambiguous condition exists if name is not found."
That's not a point I addressed. (Not "one").

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#134597

On 13/02/2026 12:43, Hans Bezemer wrote:
> On 13-02-2026 09:27, Anton Ertl wrote:
>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>>> On 12-02-2026 08:35, Anton Ertl wrote:
>>>> [...] small implementations
>>>> pick and choose from the standard requirements anyway, even among the
>>>> requirements for CORE words.  The CORE wordset has only been a
>>>> goalpost for peoplle who implement Forth as an exercise.
>> ...
>>> I don't think that people who are "implementing Forth as an exercise"
>>> can be bothered to make it "a standard compiler".
>>
>> The point is not standard conformance, but a goalpost: To have
>> something to direct the work, and also to have something that tells
>> the implementor when the project is complete.
>>
>>> And although wordsets build modularity (which I welcome) it becomes
>>> useless when it requires you to patch wordsets already implemented.
>>
>> Who is "you" in this sentence?  Given that you write "implemented",
>> you seem to argue that the standard requires the system implementor to
>> implement the base word, and then to patch it.  This is not the case.
>> The system implementor who has decided to implement the FILE words in
>> addition to the CORE words can implement the FILE version of S" from
>> the start, without any patching.
>>
>> Note also that the FILE version of S" conforms to the requirements for
>> the CORE version of S", and that's generally the case for the extended
>> versions of words.  E.g., the specification of CORE's POSTPONE
>> includes
>>
>> | An ambiguous condition exists if name is not found.
>>
>> so it does not specify what "POSTPONE 123" means.  The proposed
>> recognizer version of POSTPONE specifies that.
>>
>> - anton
> 
> I could have used "one" - wouldn't have changed the meaning. Nice 
> "Whataboutism"! The argument was (and is) what use has a standard for a 
> toy compiler?

There's another point I think you're missing. I just looked on at my 
Forth test suite on GitHub and 78 people have found it useful enough to 
give it a star. I've no idea whether they are all developing their own 
"toy" system but I would guess most are, and their system has to have 
some testing. I suggest that the easiest way is to use an existing test 
suite. As far as I know there is only one, so that automatically leads 
them to make their system (at least partially) standard compliant. An 
unexpected (and unintended) consequence of having a test suite.

Things are done when "one" says they're done. You (like
> "Anton") overestimate the authority of a standards body greatly. 
> Especially when the language concerned is almost dead. There are more 
> people implementing that compiler than writing programs for it!
> 
> And yes - it often happens (I speak from my own experience) that "one" 
> (now clear for you? :) thinks - "that's as far as I want/need to go" and 
> consider otherwise later. And yeah, then "one" has to patch it. Because 
> the word *IS* already defined "one" has to extend its functionality.
> 
> "An ambiguous condition exists if name is not found."
> That's not a point I addressed. (Not "one").I just looked on GitHub
> 
> Hans Bezemer
> 

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#134598

On 14/02/2026 10:50 am, Gerry Jackson wrote:
> On 13/02/2026 12:43, Hans Bezemer wrote:
>> On 13-02-2026 09:27, Anton Ertl wrote:
>>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>>>> On 12-02-2026 08:35, Anton Ertl wrote:
>>>>> [...] small implementations
>>>>> pick and choose from the standard requirements anyway, even among the
>>>>> requirements for CORE words.  The CORE wordset has only been a
>>>>> goalpost for peoplle who implement Forth as an exercise.
>>> ...
>>>> I don't think that people who are "implementing Forth as an exercise"
>>>> can be bothered to make it "a standard compiler".
>>>
>>> The point is not standard conformance, but a goalpost: To have
>>> something to direct the work, and also to have something that tells
>>> the implementor when the project is complete.
>>>
>>>> And although wordsets build modularity (which I welcome) it becomes
>>>> useless when it requires you to patch wordsets already implemented.
>>>
>>> Who is "you" in this sentence?  Given that you write "implemented",
>>> you seem to argue that the standard requires the system implementor to
>>> implement the base word, and then to patch it.  This is not the case.
>>> The system implementor who has decided to implement the FILE words in
>>> addition to the CORE words can implement the FILE version of S" from
>>> the start, without any patching.
>>>
>>> Note also that the FILE version of S" conforms to the requirements for
>>> the CORE version of S", and that's generally the case for the extended
>>> versions of words.  E.g., the specification of CORE's POSTPONE
>>> includes
>>>
>>> | An ambiguous condition exists if name is not found.
>>>
>>> so it does not specify what "POSTPONE 123" means.  The proposed
>>> recognizer version of POSTPONE specifies that.
>>>
>>> - anton
>>
>> I could have used "one" - wouldn't have changed the meaning. Nice "Whataboutism"! The argument was (and is) what use has a standard for a toy compiler?
> 
> There's another point I think you're missing. I just looked on at my Forth test suite on GitHub and 78 people have found it useful enough to give it a star. I've no idea whether they are all developing their own "toy" system but I would guess most are, and their system has to have some testing. I suggest that the easiest way is to use an existing test suite. As far as I know there is only one, so that automatically leads them to make their system (at least partially) standard compliant. An unexpected (and unintended) consequence of having a test suite.

Cart before horse but I agree.  First-time creators will generally pick some
standard or system because it's the easiest way.  All the thinking has been
done for one and there's a wealth of existing source from which to choose or
use as a guide.  It's a rare lion that hasn't undertaken internship as a camel.
Moore appears to have been a rebel, lone wolf, from the beginning for whom
conformity was anathema, stagnation.

[toc] | [prev] | [next] | [standalone]

#134599

In article <698fd57e$1@news.ausics.net>, dxf  <dxforth@gmail.com> wrote:
>On 14/02/2026 10:50 am, Gerry Jackson wrote:
>> On 13/02/2026 12:43, Hans Bezemer wrote:
>>> On 13-02-2026 09:27, Anton Ertl wrote:
>>>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>>>>> On 12-02-2026 08:35, Anton Ertl wrote:
>>>>>> [...] small implementations
>>>>>> pick and choose from the standard requirements anyway, even among the
>>>>>> requirements for CORE words.  The CORE wordset has only been a
>>>>>> goalpost for peoplle who implement Forth as an exercise.
>>>> ...
>>>>> I don't think that people who are "implementing Forth as an exercise"
>>>>> can be bothered to make it "a standard compiler".
>>>>
>>>> The point is not standard conformance, but a goalpost: To have
>>>> something to direct the work, and also to have something that tells
>>>> the implementor when the project is complete.
>>>>
>>>>> And although wordsets build modularity (which I welcome) it becomes
>>>>> useless when it requires you to patch wordsets already implemented.
>>>>
>>>> Who is "you" in this sentence?  Given that you write "implemented",
>>>> you seem to argue that the standard requires the system implementor to
>>>> implement the base word, and then to patch it.  This is not the case.
>>>> The system implementor who has decided to implement the FILE words in
>>>> addition to the CORE words can implement the FILE version of S" from
>>>> the start, without any patching.
>>>>
>>>> Note also that the FILE version of S" conforms to the requirements for
>>>> the CORE version of S", and that's generally the case for the extended
>>>> versions of words.  E.g., the specification of CORE's POSTPONE
>>>> includes
>>>>
>>>> | An ambiguous condition exists if name is not found.
>>>>
>>>> so it does not specify what "POSTPONE 123" means.  The proposed
>>>> recognizer version of POSTPONE specifies that.
>>>>
>>>> - anton
>>>
>>> I could have used "one" - wouldn't have changed the meaning. Nice "Whataboutism"! The argument was (and is) what use has a standard for a
>toy compiler?
>>
>> There's another point I think you're missing. I just looked on at my Forth test suite on GitHub and 78 people have found it useful enough to
>give it a star. I've no idea whether they are all developing their own "toy" system but I would guess most are, and their system has to have
>some testing. I suggest that the easiest way is to use an existing test suite. As far as I know there is only one, so that automatically leads
>them to make their system (at least partially) standard compliant. An unexpected (and unintended) consequence of having a test suite.
>
>Cart before horse but I agree.  First-time creators will generally pick some
>standard or system because it's the easiest way.  All the thinking has been
>done for one and there's a wealth of existing source from which to choose or
>use as a guide.  It's a rare lion that hasn't undertaken internship as a camel.
>Moore appears to have been a rebel, lone wolf, from the beginning for whom
>conformity was anathema, stagnation.
>

You have to test also the words you define yourself. The best is to
come up with complete test for each word, in combination with the
specification and the definition.
This is an example from ciforth:

worddoc( {LOGIC},{0=},{zero_equals},{n --- ff},{ISO,FIG},
{Leave a true flag forthvar({ff}) is the number forthvar({n})
is equal to zero, otherwise leave a false flag.
It may be aliased to forthcode({NOT}) , which inverts a flag.
},{{=},{0<}},
{ {0 0= .},{_T_},
  {  1 0= .},{0},
  {  -1 0= .},{0} },
enddoc)
CODE_HEADER({0=},{ZEQU})    dnl ZEQU is the name used in the assembler file.
        POP     AX      _C{S2}
        AND     AX,AX
        SETZ    AL
        MOVZX   AX,AL
        NEG     AX
        _PUSH
_C

Stack effect, properties, specifications, also's , tests and
code.

(Macro _PUSH has inside a _NEXT. )

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#134617

On 15/02/2026 11:33 pm, albert@spenarnc.xs4all.nl wrote:
> In article <698fd57e$1@news.ausics.net>, dxf  <dxforth@gmail.com> wrote:
>> On 14/02/2026 10:50 am, Gerry Jackson wrote:
>>> ...
>>> There's another point I think you're missing. I just looked on at my Forth test suite on GitHub and 78 people have found it useful enough to
>> give it a star. I've no idea whether they are all developing their own "toy" system but I would guess most are, and their system has to have
>> some testing. I suggest that the easiest way is to use an existing test suite. As far as I know there is only one, so that automatically leads
>> them to make their system (at least partially) standard compliant. An unexpected (and unintended) consequence of having a test suite.
>>
>> Cart before horse but I agree.  First-time creators will generally pick some
>> standard or system because it's the easiest way.  All the thinking has been
>> done for one and there's a wealth of existing source from which to choose or
>> use as a guide.  It's a rare lion that hasn't undertaken internship as a camel.
>> Moore appears to have been a rebel, lone wolf, from the beginning for whom
>> conformity was anathema, stagnation.
>>
> 
> You have to test also the words you define yourself. The best is to
> come up with complete test for each word, in combination with the
> specification and the definition.
> This is an example from ciforth:
> 
> worddoc( {LOGIC},{0=},{zero_equals},{n --- ff},{ISO,FIG},
> {Leave a true flag forthvar({ff}) is the number forthvar({n})
> is equal to zero, otherwise leave a false flag.
> It may be aliased to forthcode({NOT}) , which inverts a flag.
> },{{=},{0<}},
> { {0 0= .},{_T_},
>   {  1 0= .},{0},
>   {  -1 0= .},{0} },
> enddoc)
> CODE_HEADER({0=},{ZEQU})    dnl ZEQU is the name used in the assembler file.
>         POP     AX      _C{S2}
>         AND     AX,AX
>         SETZ    AL
>         MOVZX   AX,AL
>         NEG     AX
>         _PUSH
> _C
> 
> Stack effect, properties, specifications, also's , tests and
> code.
> 
> (Macro _PUSH has inside a _NEXT. )

In my case the path wasn't particularly arduous as I used 'knowns' throughout - a
Fig-Forth slowly and methodically modified to match Forth-83/94 using Laxen/Perry
sources as a guide.  The Hayes' ANS core test suite was handy as a final check.
I never had the problem of dealing with a mass of untested code e.g. had I started
from scratch.  I won't say it was 'a piece of cake' at the beginning.  Modifying
very low-level code typically leaves you with a system that never even starts.

[toc] | [prev] | [next] | [standalone]

#134608

On 14-02-2026 02:53, dxf wrote:
> On 14/02/2026 10:50 am, Gerry Jackson wrote:
>> On 13/02/2026 12:43, Hans Bezemer wrote:
>>> On 13-02-2026 09:27, Anton Ertl wrote:
>>>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>>>>> On 12-02-2026 08:35, Anton Ertl wrote:
>>>>>> [...] small implementations
>>>>>> pick and choose from the standard requirements anyway, even among the
>>>>>> requirements for CORE words.  The CORE wordset has only been a
>>>>>> goalpost for peoplle who implement Forth as an exercise.
>>>> ...
>>>>> I don't think that people who are "implementing Forth as an exercise"
>>>>> can be bothered to make it "a standard compiler".
>>>>
>>>> The point is not standard conformance, but a goalpost: To have
>>>> something to direct the work, and also to have something that tells
>>>> the implementor when the project is complete.
>>>>
>>>>> And although wordsets build modularity (which I welcome) it becomes
>>>>> useless when it requires you to patch wordsets already implemented.
>>>>
>>>> Who is "you" in this sentence?  Given that you write "implemented",
>>>> you seem to argue that the standard requires the system implementor to
>>>> implement the base word, and then to patch it.  This is not the case.
>>>> The system implementor who has decided to implement the FILE words in
>>>> addition to the CORE words can implement the FILE version of S" from
>>>> the start, without any patching.
>>>>
>>>> Note also that the FILE version of S" conforms to the requirements for
>>>> the CORE version of S", and that's generally the case for the extended
>>>> versions of words.  E.g., the specification of CORE's POSTPONE
>>>> includes
>>>>
>>>> | An ambiguous condition exists if name is not found.
>>>>
>>>> so it does not specify what "POSTPONE 123" means.  The proposed
>>>> recognizer version of POSTPONE specifies that.
>>>>
>>>> - anton
>>>
>>> I could have used "one" - wouldn't have changed the meaning. Nice "Whataboutism"! The argument was (and is) what use has a standard for a toy compiler?
>>
>> There's another point I think you're missing. I just looked on at my Forth test suite on GitHub and 78 people have found it useful enough to give it a star. I've no idea whether they are all developing their own "toy" system but I would guess most are, and their system has to have some testing. I suggest that the easiest way is to use an existing test suite. As far as I know there is only one, so that automatically leads them to make their system (at least partially) standard compliant. An unexpected (and unintended) consequence of having a test suite.
> 
> Cart before horse but I agree.  First-time creators will generally pick some
> standard or system because it's the easiest way.  All the thinking has been
> done for one and there's a wealth of existing source from which to choose or
> use as a guide.  It's a rare lion that hasn't undertaken internship as a camel.
> Moore appears to have been a rebel, lone wolf, from the beginning for whom
> conformity was anathema, stagnation.
> 

Read what you're saying: "SOME standard or system". Not necessarily an 
ANS-kind of system. I think a newbie will rather rip something from the 
web that works and use that as a template than take a paper standard and 
try to replicate that one.

If I dig into my own history - I took the Forth-79 standard, took the 
most essential parts from it and started from there - AKA it wasn't even 
a FULL Forth-79 system. The move to ANS started several versions later.

So no - I don't swallow the argument "a CORE wordset is useful for bare 
implementations". I even wonder if they take a look at all. Or if they 
even care. If I may believe the presentations of recent Forth 
experiments, not at all.

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#134609 — Evolution of Forths was Re: Recognizer proposal

In article <nnd$0ad3ab77$499f67d9@7973d9f3cc5a9d2e>,
Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
>On 14-02-2026 02:53, dxf wrote:
>> Cart before horse but I agree.  First-time creators will generally pick some
>> standard or system because it's the easiest way.  All the thinking has been
>> done for one and there's a wealth of existing source from which to choose or
>> use as a guide.  It's a rare lion that hasn't undertaken internship as a camel.
>> Moore appears to have been a rebel, lone wolf, from the beginning for whom
>> conformity was anathema, stagnation.
>>
>
>Read what you're saying: "SOME standard or system". Not necessarily an
>ANS-kind of system. I think a newbie will rather rip something from the
>web that works and use that as a template than take a paper standard and
>try to replicate that one.

Maybe, maybe not. If you don't know anything about Forth and want to
learn e.g. Haskell, and consider Forth as an exercise it is possible
that you start with the CORE description.

>
>If I dig into my own history - I took the Forth-79 standard, took the
>most essential parts from it and started from there - AKA it wasn't even
>a FULL Forth-79 system. The move to ANS started several versions later.

I was used to fig-Forth, and scanned the fig-Forth documentation and
ocr-ed it. Contributed to Z80, using blocks-in-files for CPM, later MSDOS.
These were used for real programs. Around 1990 for a campaign of the
socialist party (SP), millions of addresses where printed for personal
letters, based on street databases. Pallets of chain printing stickers.

>So no - I don't swallow the argument "a CORE wordset is useful for bare
>implementations". I even wonder if they take a look at all. Or if they
>even care. If I may believe the presentations of recent Forth
>experiments, not at all.

So once the ISO93 came along, I adapted an MSDOS Forth, then evolved
it to 32 bits, then ported to Windows and linux, then evolved it to 64 bits.
Practical additions are the file wordset, and standard in/standard out,
the latter not guided by a standard.
All the way I was concerned with compatibility and programs keep running.
In practice that meant all the stuff from fig-Forth needed for
programming in practice, was kept.
It was accidental that the CORE set was a part of this.

The DEC Alpha came along. This means changing the assembler source, to
wit only the pieces written in assembly, not the headers, not the
documentation, not the test. That was done within 14 days wall clock
time (not 8 working hours!).

All programs that work in this model, kept working on the DEC Alpha.

Willem Ouwerkerk c.s. developed many Forths for small SBC (8051, etc.)
This was done with a so called metacompiler. Once you get used to
this tool, it is comparitively easy to port to new microprocessors.
In this development path, the first thing you do is to write a
Forth assembler for the new processor, then insert the uP-dependant
stuff into the metacompiler tool.
In this way the meta sources determine what is present, possibly
a bit idiosyncratic.

I consider my assembler sources more valuable than an open source
metacompiler system, so I choose that route.


>
>Hans Bezemer
>

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#134610 — Re: Evolution of Forths was Re: Recognizer proposal

On 20/02/2026 12:38 am, albert@spenarnc.xs4all.nl wrote:
> ... 
> Willem Ouwerkerk c.s. developed many Forths for small SBC (8051, etc.)
> This was done with a so called metacompiler. Once you get used to
> this tool, it is comparitively easy to port to new microprocessors.
> In this development path, the first thing you do is to write a
> Forth assembler for the new processor, then insert the uP-dependant
> stuff into the metacompiler tool.
> In this way the meta sources determine what is present, possibly
> a bit idiosyncratic.
> 
> I consider my assembler sources more valuable than an open source
> metacompiler system, so I choose that route.

Not only was native assembler easier for me as I mentioned, it was
considerably faster.  Running the F83 metacompiler on a 4MHz Z80 was
painfully slow.  On top of this I'd have needed to modify it to do
dictionary segmenting - my prime motivation in creating a forth.
Even the ubiquitous M80 CP/M assembler proved too slow and I invested
in an SLR Systems assembler.  Given the number of compiles I did in
development it was easily the best money I ever spent on software.
Not that I wasn't forced to learn new stuff.  Macros, code segmentation,
etc gave me enough headaches.  Looking back it seems crazy.  No regrets
however as I began to realize this was more my niche than writing
applications.  That said, if one doesn't write apps there's no way to
evaluate the effectiveness of a given forth.  How many forths never got
past creation because the author's interest waned.  For these the list
of words in ANS etc suffices.  But the forth one uses is something else.
It's the difference between a living tree and what comprises trees.
Standards are an obsession with the latter and kind of misses the point.

[toc] | [prev] | [next] | [standalone]

#134611 — Re: Evolution of Forths was Re: Recognizer proposal

In article <6997b9e1$1@news.ausics.net>, dxf  <dxforth@gmail.com> wrote:
>On 20/02/2026 12:38 am, albert@spenarnc.xs4all.nl wrote:
>> ...
>> Willem Ouwerkerk c.s. developed many Forths for small SBC (8051, etc.)
>> This was done with a so called metacompiler. Once you get used to
>> this tool, it is comparitively easy to port to new microprocessors.
>> In this development path, the first thing you do is to write a
>> Forth assembler for the new processor, then insert the uP-dependant
>> stuff into the metacompiler tool.
>> In this way the meta sources determine what is present, possibly
>> a bit idiosyncratic.
>>
>> I consider my assembler sources more valuable than an open source
>> metacompiler system, so I choose that route.
>
>Not only was native assembler easier for me as I mentioned, it was
>considerably faster.  Running the F83 metacompiler on a 4MHz Z80 was
>painfully slow.  On top of this I'd have needed to modify it to do
>dictionary segmenting - my prime motivation in creating a forth.
>Even the ubiquitous M80 CP/M assembler proved too slow and I invested
>in an SLR Systems assembler.  Given the number of compiles I did in
>development it was easily the best money I ever spent on software.
>Not that I wasn't forced to learn new stuff.  Macros, code segmentation,
>etc gave me enough headaches.  Looking back it seems crazy.  No regrets
>however as I began to realize this was more my niche than writing
>applications.  That said, if one doesn't write apps there's no way to
>evaluate the effectiveness of a given forth.  How many forths never got
>past creation because the author's interest waned.  For these the list
>of words in ANS etc suffices.  But the forth one uses is something else.
>It's the difference between a living tree and what comprises trees.
>Standards are an obsession with the latter and kind of misses the point.
>

All tools running on windows/linux are fast,
The metacompilers do not run on the sbc and take at most seconds.

Especially assemblers, building ciforth is in the milliseconds.
(What they say in a blink of an eye).

~/PROJECT/ciforths/ciforth: time fasm ci86.lina64.fas -m256000
flat assembler  version 1.70.02  (256000 kilobytes memory)
2 passes, 56376 bytes.

real    0m0.030s
user    0m0.014s
sys     0m0.012s

fasm eliminates a separate link step, that make no sense anyway
for assemblers.
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#134618 — Re: Evolution of Forths was Re: Recognizer proposal

On 20/02/2026 9:58 pm, albert@spenarnc.xs4all.nl wrote:
> In article <6997b9e1$1@news.ausics.net>, dxf  <dxforth@gmail.com> wrote:
>> On 20/02/2026 12:38 am, albert@spenarnc.xs4all.nl wrote:
>>> ...
>>> Willem Ouwerkerk c.s. developed many Forths for small SBC (8051, etc.)
>>> This was done with a so called metacompiler. Once you get used to
>>> this tool, it is comparitively easy to port to new microprocessors.
>>> In this development path, the first thing you do is to write a
>>> Forth assembler for the new processor, then insert the uP-dependant
>>> stuff into the metacompiler tool.
>>> In this way the meta sources determine what is present, possibly
>>> a bit idiosyncratic.
>>>
>>> I consider my assembler sources more valuable than an open source
>>> metacompiler system, so I choose that route.
>>
>> Not only was native assembler easier for me as I mentioned, it was
>> considerably faster.  Running the F83 metacompiler on a 4MHz Z80 was
>> painfully slow.  On top of this I'd have needed to modify it to do
>> dictionary segmenting - my prime motivation in creating a forth.
>> Even the ubiquitous M80 CP/M assembler proved too slow and I invested
>> in an SLR Systems assembler.  Given the number of compiles I did in
>> development it was easily the best money I ever spent on software.
>> Not that I wasn't forced to learn new stuff.  Macros, code segmentation,
>> etc gave me enough headaches.  Looking back it seems crazy.  No regrets
>> however as I began to realize this was more my niche than writing
>> applications.  That said, if one doesn't write apps there's no way to
>> evaluate the effectiveness of a given forth.  How many forths never got
>> past creation because the author's interest waned.  For these the list
>> of words in ANS etc suffices.  But the forth one uses is something else.
>> It's the difference between a living tree and what comprises trees.
>> Standards are an obsession with the latter and kind of misses the point.
>>
> 
> All tools running on windows/linux are fast,
> The metacompilers do not run on the sbc and take at most seconds.
> 
> Especially assemblers, building ciforth is in the milliseconds.
> (What they say in a blink of an eye).

Metacompilers have an air of cleverness but come with so many hurdles that
frankly if there's an alternate tool I'll use that.  I don't blame William
Payne (8051 FigForth) in the least for hiring Nautilus Systems to write his
metacompilers, or C.H. Ting for translating Bill Muench's metacompiler-based
eForth to MASM.  I figure there's enough masochism in Forth already without
looking for more ;-)

[toc] | [prev] | [next] | [standalone]

#134613 — Re: Evolution of Forths was Re: Recognizer proposal

On 20-02-2026 02:33, dxf wrote:
> On 20/02/2026 12:38 am, albert@spenarnc.xs4all.nl wrote:
>> ...
>> Willem Ouwerkerk c.s. developed many Forths for small SBC (8051, etc.)
>> This was done with a so called metacompiler. Once you get used to
>> this tool, it is comparitively easy to port to new microprocessors.
>> In this development path, the first thing you do is to write a
>> Forth assembler for the new processor, then insert the uP-dependant
>> stuff into the metacompiler tool.
>> In this way the meta sources determine what is present, possibly
>> a bit idiosyncratic.
>>
>> I consider my assembler sources more valuable than an open source
>> metacompiler system, so I choose that route.
> 
> Not only was native assembler easier for me as I mentioned, it was
> considerably faster.  Running the F83 metacompiler on a 4MHz Z80 was
> painfully slow.  On top of this I'd have needed to modify it to do
> dictionary segmenting - my prime motivation in creating a forth.
> Even the ubiquitous M80 CP/M assembler proved too slow and I invested
> in an SLR Systems assembler.  Given the number of compiles I did in
> development it was easily the best money I ever spent on software.
> Not that I wasn't forced to learn new stuff.  Macros, code segmentation,
> etc gave me enough headaches.  Looking back it seems crazy.  No regrets
> however as I began to realize this was more my niche than writing
> applications.  That said, if one doesn't write apps there's no way to
> evaluate the effectiveness of a given forth.  How many forths never got
> past creation because the author's interest waned.  For these the list
> of words in ANS etc suffices.  But the forth one uses is something else.
> It's the difference between a living tree and what comprises trees.
> Standards are an obsession with the latter and kind of misses the point.
> 

You're hitting the nail on the head: if making a Forth compiler is the 
only goal, then what use is it to make it "standards compatible". A 
Forth compiler is no different from any other program: if the goal is 
"just making it work" then essentially the purpose is fulfilled once 
it's done.

But useful programs (if only in the eye of the beholder) are USED. They 
live. They fail. They develop (as you stated - often beyond standards).

IMHO opinion standards are only useful if they have to be transferred - 
from person to person or from platform to platform. I can't say I 
haven't benefited from that idea in one way or another. But like you 
said - let's keep its true value realistic and pragmatic.

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#134619 — Re: Evolution of Forths was Re: Recognizer proposal

On 22/02/2026 2:35 am, Hans Bezemer wrote:
> ... 
> IMHO opinion standards are only useful if they have to be transferred - from person to person or from platform to platform. I can't say I haven't benefited from that idea in one way or another. But like you said - let's keep its true value realistic and pragmatic.

The standard is useful to me to the extent there's a bunch of words I don't
have to adjust or translate in order to get some code I encounter working
without having to tear my hair out.  OTOH were I follower that depended on
standards for features and portability in the way users of other languages
do, I would be less satisfied.  The standard Forth offers is akin to a Swiss
cheese whose holes increase in size as individual forths attempt to fill the
gaps.

[toc] | [prev] | [next] | [standalone]

#134622

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> I still think that meddling with the text interpreter is a big no-no
> and an invitation to disaster.

Yes, S" 12.34e" >FLOAT is quite horrible, but having the behaviour of
"123.45" change depending on whether the floating point wordset is
loaded is also horrible.  Probably best to leave things as they are, and
maybe suggest a nonstandard extension to treat 123.45 as a float.  To
get a double cell you'd use 

It does seem to me that with 32-bit systems widespread, double ints have
gotten less important.  I wouldn't want the standard behaviour to
change, but I'd probably use the nonstandard extension if it existed.
With the extension turned on, to get the double int, you'd use 12345 0
or maybe something like "D# 123 45" .

Double ints are maybe still useful on 8 bit systems with 16 bit cells.

[toc] | [prev] | [next] | [standalone]

#134623

Paul Rubin <no.email@nospam.invalid> writes:
>Probably best to leave things as they are, and
>maybe suggest a nonstandard extension to treat 123.45 as a float.

Actually, if the proposal is accepted as-is, there will be a
semi-standardized way to switch the Forth system to accept 123.45 as a
float: REC-FLOAT is allowed (but not required) to recognize "123.45",
and by putting REC-FLOAT ahead of REC-NUMBER in the recognizer
sequence REC-FORTH, the user can eliminate the shadowing of "123.45"
by REC-NUMBER.

Alternatively, the user can define REC-NUMBER1, which only recognizes
doubles with a prefix (i.e., not "123.45"), and replace occurrences of
REC-NUMBER with REC-NUMBER1 in REC-FORTH.  This also eliminates the
shadowing.  Or, if you really never want doubles, define REC-CELL
which does not recognize doubles at all, and replace REC-NUMBER by
REC-CELL.

This all works in Gforth, we will see what REC-FLOAT recognizes in
other systems.

>It does seem to me that with 32-bit systems widespread, double ints have
>gotten less important.

Even with 64-bit cells, doubles are important for mixed-length
arithmetics, which is important for building multi-precision
arithmetics, used for cryptography and various mathematical
applications.

>With the extension turned on, to get the double int, you'd use 12345 0
>or maybe something like "D# 123 45" .

#12345. and $DEADBEEF. are standard ways to write a double that is not
recognized by REC-FLOAT.

Concerning group separators, Gforth (development) ignores _ as a group
separator, including in singles:

18_446_744_073_709_551_615

Many Forth systems accept multiple dots in numbers, which can be used
as group separators, but the result then is a double; some also accept
comma as double indicator as well as multiple double indicators, so
you can write numbers with "," as group separator and "." as decimal
mark, or with "." as group separator and "," as decimal mark; but
again, the result is a double.  Given the sizes of some singles in
32-bit and 64-bit systems, a way to provide group separators
without turning the number into a double is useful.

Gforth does not have a convenient way to produce the group separator
on output, yet.

- 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 2025 proceedings: http://www.euroforth.org/ef25/papers/

[toc] | [prev] | [next] | [standalone]

#134624

In article <87qzq8b07r.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Hans Bezemer <the.beez.speaks@gmail.com> writes:
>> I still think that meddling with the text interpreter is a big no-no
>> and an invitation to disaster.
>
>Yes, S" 12.34e" >FLOAT is quite horrible, but having the behaviour of
>"123.45" change depending on whether the floating point wordset is
>loaded is also horrible.  Probably best to leave things as they are, and
>maybe suggest a nonstandard extension to treat 123.45 as a float.  To
>get a double cell you'd use

Offically 123.45 is not a double number. It should end with a decimal point.

How is the support for a proposal:

Double numbers should start and end with a dot.
Now any numbers containing a single dot are automatically fp

A program that uses single dots to indicate doubles, should
declare an environmental dependancy. The default behaviour it
that they are floats.

In this way most programs that uses fp and use single dots are
fully compliant.

There are people who are font of 01/02/03 date (2003 januari 2 )
indications that are examples in Starting Forth.
You could do this with recognizers (I suppose).

>
>It does seem to me that with 32-bit systems widespread, double ints have
>gotten less important.  I wouldn't want the standard behaviour to
>change, but I'd probably use the nonstandard extension if it existed.
>With the extension turned on, to get the double int, you'd use 12345 0
>or maybe something like "D# 123 45" .
>
>Double ints are maybe still useful on 8 bit systems with 16 bit cells.

I have published yourforth, an altenative to jonesforth. It is 32 bits
and I have eliminated all double precision crap, contributing to
it pedagogical value.

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#134626

On 26/02/2026 11:09 pm, albert@spenarnc.xs4all.nl wrote:
> In article <87qzq8b07r.fsf@nightsong.com>,
> Paul Rubin  <no.email@nospam.invalid> wrote:
>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>>> I still think that meddling with the text interpreter is a big no-no
>>> and an invitation to disaster.
>>
>> Yes, S" 12.34e" >FLOAT is quite horrible, but having the behaviour of
>> "123.45" change depending on whether the floating point wordset is
>> loaded is also horrible.  Probably best to leave things as they are, and
>> maybe suggest a nonstandard extension to treat 123.45 as a float.  To
>> get a double cell you'd use
> 
> Offically 123.45 is not a double number. It should end with a decimal point.
> 
> How is the support for a proposal:
> 
> Double numbers should start and end with a dot.
> Now any numbers containing a single dot are automatically fp
> 
> A program that uses single dots to indicate doubles, should
> declare an environmental dependancy. The default behaviour it
> that they are floats.
> 
> In this way most programs that uses fp and use single dots are
> fully compliant.
> 
> There are people who are font of 01/02/03 date (2003 januari 2 )
> indications that are examples in Starting Forth.

And those who see it as a vulnerability:

  garbage in  -->  valid number out

> You could do this with recognizers (I suppose).

Given the cost of recognizers one hopes it can do better :)

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.forth

csiph-web