I don't want $ # % in the kernel

[none) (albert]

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.

[[e-mail]]

Post by none) (albert
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).
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 !
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

[none) (albert]

In article <ac6c05eb-a1b5-4497-8541-***@googlegroups.com>,
***@arcor.de <***@arcor.de> wrote:
<SNIP>

Post by ***@arcor.de
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

<SNIP>
Your conclusion is : as long as I don't load those prefixes for % etc.
the system is not 2012 standard conforming.

Post by ***@arcor.de
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

[Lorem Ipsum]

Post by none) (albert
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.

[none) (albert]

Post by Lorem Ipsum

Post by none) (albert
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.

Post by Lorem Ipsum
Rick C.

Groetjes Albert

[[e-mail]]

Post by none) (albert

Post by Lorem Ipsum

Post by none) (albert
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.

[dxforth]

Post by none) (albert
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).
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 !
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 :)

[none) (albert]

Post by dxforth

Post by none) (albert
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).
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 !
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.

Post by dxforth
(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