I invented prefixes e.g. $ as a loadable extension in order to
run Marcel Hendrix programs. mhx pioneered the use of prefixes.
I didn't want $ in the kernel, because it wasn't even standard
at the time (2000).

In ciforth all numbers and strings are handled by prefixes:
0 1 .. 9 " '
ONLY is a wordlist (OK it is a name of a wordlist) and
contains this stuff. So I can add $ # % as prefixes in
a regular fashion if I make ONLY the wordlist where
definitions are added.

'ONLY >WID CURRENT !
: $ BASE @ >R HEX (NUMBER) R> BASE ! POSTPONE SDLITERAL ;
PREFIX IMMEDIATE 1]

(NUMBER) handles a number from the input stream.
SDLITERAL compiles/interprets a single/double number.
So far so good.

Can I claim compatibility with the 2012 standard (in this
respect) if I supply $ # % as loadable extensions?

Groetjes Albert

1]
PREFIX is a trivial extension. A prefix is found as
it matches the first part of a word.
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

none albert schrieb am Montag, 12. Dezember 2022 um 17:25:26 UTC+1:
> I invented prefixes e.g. $ as a loadable extension in order to
> run Marcel Hendrix programs. mhx pioneered the use of prefixes.
> I didn't want $ in the kernel, because it wasn't even standard
> at the time (2000).
>
> In ciforth all numbers and strings are handled by prefixes:
> 0 1 .. 9 " '
> ONLY is a wordlist (OK it is a name of a wordlist) and
> contains this stuff. So I can add $ # % as prefixes in
> a regular fashion if I make ONLY the wordlist where
> definitions are added.
>
> 'ONLY >WID CURRENT !
> : $ BASE @ >R HEX (NUMBER) R> BASE ! POSTPONE SDLITERAL ;
> PREFIX IMMEDIATE 1]
>
> (NUMBER) handles a number from the input stream.
> SDLITERAL compiles/interprets a single/double number.
> So far so good.
>
> Can I claim compatibility with the 2012 standard (in this
> respect) if I supply $ # % as loadable extensions?
>
> Groetjes Albert
>
> 1]
> PREFIX is a trivial extension. A prefix is found as
> it matches the first part of a word.

When the extension is NOT loaded, the text interpreter should
still fulfill § 3.1.4.3 of the standard document IMO. It is a general
requirement (not part of any word set) and stipulates the following
number recognition forms:

⟨anynum⟩ := { ⟨BASEnum⟩ | ⟨decnum⟩ | ⟨hexnum⟩ | ⟨binnum⟩ | ⟨cnum⟩ }
⟨BASEnum⟩ := [-]⟨bdigit⟩⟨bdigit⟩*
⟨decnum⟩ := #[-]⟨decdigit⟩⟨decdigit⟩*
⟨hexnum⟩ := $[-]⟨hexdigit⟩⟨hexdigit⟩*
⟨binnum⟩ := %[-]⟨bindigit⟩⟨bindigit⟩*
⟨cnum⟩ := ’⟨char⟩’
⟨bindigit⟩ := { 0 | 1 }
⟨decdigit⟩ := { 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 }
⟨hexdigit⟩ := { ⟨decdigit⟩ | a | b | c | d | e | f | A | B | C | D | E | F

When the extension IS loaded, your prefix recognition is part of the
dictionary and standard prefixed number recognition does not come into play

In article <ac6c05eb-a1b5-4497-8541-886b9ae1af28n@googlegroups.com>,
minf...@arcor.de <minforth@arcor.de> wrote:
<SNIP>
>When the extension is NOT loaded, the text interpreter should
>still fulfill § 3.1.4.3 of the standard document IMO. It is a general
>requirement (not part of any word set) and stipulates the following
>number recognition forms:
<SNIP>
Your conclusion is : as long as I don't load those prefixes for % etc.
the system is not 2012 standard conforming.

>
>When the extension IS loaded, your prefix recognition is part of the
>dictionary and standard prefixed number recognition does not come into play

What do you mean by this?

Groetjes Albert
>
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Monday, December 12, 2022 at 12:25:26 PM UTC-4, none albert wrote:
> I invented prefixes e.g. $ as a loadable extension in order to
> run Marcel Hendrix programs. mhx pioneered the use of prefixes.
> I didn't want $ in the kernel, because it wasn't even standard
> at the time (2000).

Not trying to be a pain, but why exactly would it be an issue to implement $ prefix in the kernel? Aren't there many words defined in the kernel that are not part of the standard? Does including some feature that is not standard, make the implementation non-standard? I'm not following.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On 13/12/2022 3:25 am, albert wrote:
> I invented prefixes e.g. $ as a loadable extension in order to
> run Marcel Hendrix programs. mhx pioneered the use of prefixes.
> I didn't want $ in the kernel, because it wasn't even standard
> at the time (2000).
>
> In ciforth all numbers and strings are handled by prefixes:
> 0 1 .. 9 " '
> ONLY is a wordlist (OK it is a name of a wordlist) and
> contains this stuff. So I can add $ # % as prefixes in
> a regular fashion if I make ONLY the wordlist where
> definitions are added.
>
> 'ONLY >WID CURRENT !
> : $ BASE @ >R HEX (NUMBER) R> BASE ! POSTPONE SDLITERAL ;
> PREFIX IMMEDIATE 1]
>
> (NUMBER) handles a number from the input stream.
> SDLITERAL compiles/interprets a single/double number.
> So far so good.
>
> Can I claim compatibility with the 2012 standard (in this
> respect) if I supply $ # % as loadable extensions?

As long as one doesn't conflate 'kernel' with 'core' then I don't
see an issue. IMO all that's necessary is to document what steps
a user needs to take to make the system 'standard compliant'.
(TBH ciForth never struck me as a beginner's system and appeals
to the latter will be somewhat lost :)

In article <ce0ea924-ecba-43a7-bbc5-06f4f9f52b6an@googlegroups.com>,
Lorem Ipsum <gnuarm.deletethisbit@gmail.com> wrote:
>On Monday, December 12, 2022 at 12:25:26 PM UTC-4, none albert wrote:
>> I invented prefixes e.g. $ as a loadable extension in order to
>> run Marcel Hendrix programs. mhx pioneered the use of prefixes.
>> I didn't want $ in the kernel, because it wasn't even standard
>> at the time (2000).
>
>Not trying to be a pain, but why exactly would it be an issue to
>implement $ prefix in the kernel? Aren't there many words defined in
>the kernel that are not part of the standard? Does including some
>feature that is not standard, make the implementation non-standard? I'm
>not following.

The computer intelligence Forth (original meaning) was intended to
be modular, and introspective, running stand alone on computer.
Each word has a source field pointing at its source, modifying the
source (followed by compilation) should change the word on the fly.
Each word possess a exclusive part of the memory.
That would mean that the startup part of Forth should be minimal,
say initializing registers and setting up virtual memory.
In this vein number handling should be modular and in fact it is.
You can get rid of %1000 numbers to toggle the INVISIBLE bit
in the word %.

Why not implement $ in the kernel?
It has no use in the kernel, and I hate it. So I want to ban
it to a loadable extension.

Many non-standard words in the kernel?
I don't allow words on the kernel that are no use.
It follows that any non-standard words in my kernel are
eminently useful. $ is not one of them.

Does including some feature that is not standard, make the
implementation non-standard?
Of course not. However I don't intend to use that as an excuse
to add the proverbial kitchen sink to a kernel.

>Rick C.

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

In article <tn8mtm$gln$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
>On 13/12/2022 3:25 am, albert wrote:
>> I invented prefixes e.g. $ as a loadable extension in order to
>> run Marcel Hendrix programs. mhx pioneered the use of prefixes.
>> I didn't want $ in the kernel, because it wasn't even standard
>> at the time (2000).
>>
>> In ciforth all numbers and strings are handled by prefixes:
>> 0 1 .. 9 " '
>> ONLY is a wordlist (OK it is a name of a wordlist) and
>> contains this stuff. So I can add $ # % as prefixes in
>> a regular fashion if I make ONLY the wordlist where
>> definitions are added.
>>
>> 'ONLY >WID CURRENT !
>> : $ BASE @ >R HEX (NUMBER) R> BASE ! POSTPONE SDLITERAL ;
>> PREFIX IMMEDIATE 1]
>>
>> (NUMBER) handles a number from the input stream.
>> SDLITERAL compiles/interprets a single/double number.
>> So far so good.
>>
>> Can I claim compatibility with the 2012 standard (in this
>> respect) if I supply $ # % as loadable extensions?
>
>As long as one doesn't conflate 'kernel' with 'core' then I don't
>see an issue. IMO all that's necessary is to document what steps
>a user needs to take to make the system 'standard compliant'.

That is a good idea.

ciforth comes with options. -a attaches the library
-e (elective) load tools -v show version information required by gnu

Starting up as (pedantic)
lina -p
Properly implemented that could satisfy all language lawyers.

>(TBH ciForth never struck me as a beginner's system and appeals
>to the latter will be somewhat lost :)
Experience Forthers are not interested in standard compliance?

I do my best to make it usable for beginners.
E.g. my glossary is subdivided in wordsets, each preceded by a
description what belongs to the wordset.
The documentation has an index into that glossary, there is a separate
index for concepts. The pdf has a collapsible expandable left side.
etc.
But the Forth is small, good for an overview, bad for running
programs that use some of the rarer words in the standards.

>
Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

none albert schrieb am Dienstag, 13. Dezember 2022 um 11:05:14 UTC+1:
> In article <ce0ea924-ecba-43a7...@googlegroups.com>,
> Lorem Ipsum <gnuarm.del...@gmail.com> wrote:
> >On Monday, December 12, 2022 at 12:25:26 PM UTC-4, none albert wrote:
> >> I invented prefixes e.g. $ as a loadable extension in order to
> >> run Marcel Hendrix programs. mhx pioneered the use of prefixes.
> >> I didn't want $ in the kernel, because it wasn't even standard
> >> at the time (2000).
> >
> >Not trying to be a pain, but why exactly would it be an issue to
> >implement $ prefix in the kernel? Aren't there many words defined in
> >the kernel that are not part of the standard? Does including some
> >feature that is not standard, make the implementation non-standard? I'm
> >not following.
> The computer intelligence Forth (original meaning) was intended to
> be modular, and introspective, running stand alone on computer.
> Each word has a source field pointing at its source, modifying the
> source (followed by compilation) should change the word on the fly.
> Each word possess a exclusive part of the memory.
> That would mean that the startup part of Forth should be minimal,
> say initializing registers and setting up virtual memory.
> In this vein number handling should be modular and in fact it is.
> You can get rid of %1000 numbers to toggle the INVISIBLE bit
> in the word %.
>
> Why not implement $ in the kernel?
> It has no use in the kernel, and I hate it. So I want to ban
> it to a loadable extension.
>
> Many non-standard words in the kernel?
> I don't allow words on the kernel that are no use.
> It follows that any non-standard words in my kernel are
> eminently useful. $ is not one of them.
> Does including some feature that is not standard, make the
> implementation non-standard?
> Of course not. However I don't intend to use that as an excuse
> to add the proverbial kitchen sink to a kernel.

YMMV but I would declare even more words ripe for the kitchen sink
like STATE POSTPONE BASE LOCALS| SUBSTITUTE. There are better
alternatives. Nevertheless there is the issue of being able to run
standard Forth code. So those words still merit their place.

The same logic applies to the text interpreter and its expected
number conversion stipulated in section 3 of the Standard.
Section 5.1.1 stipulates "A system that complies with ALL the system
requirements given in sections 3 Usage requirements and 4.1
System documentation and their sub-sections is a Standard System."

But who gives a ... about Forth language lawyerism. Unless there are
stringent customer requirements I wouldn't care. Otherwise demonstrate
to him/her that your system does pass the Forth-2012 test suite
before unnecessarily modifying a well-developed and proven kernel.