single-xt approach in the standard

[Ruvim]

Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?

The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.


--
Ruvim

[minforth]

I would like to see an "officially recognized" standard reference
system, speed and number of xt's per word are of no importance.

Are you planning to make one?

[Ruvim]

Post by minforth
I would like to see an "officially recognized" standard reference
system, speed and number of xt's per word are of no importance.
Are you planning to make one?

I think, having the single standard reference implementation is a big
step back in Forth standardization process. Because implementation
details of the particular implementation will be used as requirements.

I think, the standard conformance test suite is enough.

For illustrative purposes, we can have several different implementations
of Forth in Forth.


--
Ruvim

[Anthony Howe]

Post by minforth
I would like to see an "officially recognized" standard reference
system, speed and number of xt's per word are of no importance.
Are you planning to make one?

I think, having the single standard reference implementation is a big step back
in Forth standardization process. Because implementation details of the
particular implementation will be used as requirements.

I think it should be recognised in some capacity, given Forth's origins, but
whether there should be a reference implementation probably not.

I think, the standard conformance test suite is enough.

One would think so, but the test suite is:

* incomplete
* as published in draft 19-1 has typos and possible errors
* test cases often test multiple words at once that have not be tested separately
* assumes the entire draft with all the optional sets are present, rather than
separate the word sets into separate unit tests

For illustrative purposes, we can have several different implementations of
Forth in Forth.

If there is reference implementation(s) I think it would be interesting to have
two: `single-xt` and `dual-xt` to demonstrate that both models worth and are
conforming.

[dxf]

Post by Anthony Howe
...

Post by Ruvim
I think, the standard conformance test suite is enough.

* incomplete

As is the standard generally. It's also dated. It's no coincidence
vendors provided functionality well beyond what ANS specified. Since
these extensions were never coordinated, there's no common practice
and thus no consensus. Neither are willing to risk customer backlash
on what is essentially a dead idea. Their role on the TC is to ensure
nothing jeopardizes their investment. It's impossible to have spent
20 years 'standardizing' and have achieved so little. For fans only.

[Ruvim]

Post by dxf

Post by Anthony Howe
...

Post by Ruvim
I think, the standard conformance test suite is enough.

* incomplete

As is the standard generally. It's also dated. It's no coincidence
vendors provided functionality well beyond what ANS specified.

Some words that cannot be implemented in a standard program should be
standardized, for example, sockets, multitasking, and perhaps FFI.

But libraries (except some most basic ones) should not be a part of the
Forth language standard, I think.

Post by dxf
Since
these extensions were never coordinated, there's no common practice
and thus no consensus. Neither are willing to risk customer backlash
on what is essentially a dead idea.
Their role on the TC is to ensure
nothing jeopardizes their investment. It's impossible to have spent
20 years 'standardizing' and have achieved so little.

This critics is absolutely fruitless. No one owes you to develop any
specifications unless you pay for it. Whether some people have achieved
much or little is their own business.

Do you have any specific proposals? If this bothers you, why not get
involved? Or why not develop some specifications independently?

Post by dxf
For fans only.

This is not a paid job. You have to be a fan to do this.



--
Ruvim

[dxf]

...

Post by dxf
Since
these extensions were never coordinated, there's no common practice
and thus no consensus.  Neither are willing to risk customer backlash
on what is essentially a dead idea. 
Their role on the TC is to ensure
nothing jeopardizes their investment.  It's impossible to have spent
20 years 'standardizing' and have achieved so little. 

This critics is absolutely fruitless. No one owes you to develop any specifications unless you pay for it. Whether some people have achieved much or little is their own business.

When the ANS-TC sat, they did consider it their business and priority.
They knew the world wasn't going to wait. Perhaps the situation has
changed and now it's only fans the TC need worry about. If the attitude
is 'take it or leave it', I've made that choice.

[Ruvim]

Post by dxf

...

Post by dxf
Their role on the TC is to ensure
nothing jeopardizes their investment.  It's impossible to have spent
20 years 'standardizing' and have achieved so little.

This critics is absolutely fruitless. No one owes you to develop any specifications unless you pay for it. Whether some people have achieved much or little is their own business.

When the ANS-TC sat, they did consider it their business and priority.

And what? Anybody can claim that.

Post by dxf
They knew the world wasn't going to wait. Perhaps the situation has
changed and now it's only fans the TC need worry about.
If the attitude is 'take it or leave it',

I think, you missed another option. The attitude is: take it, or make it
better, or leave it (and maybe build your own theme park).

I don't see on what basis can someone *demand* something from the TC.

Post by dxf
I've made that choice.

It seems, despite your choice, the Forth standardization process that is
based on the forth-standard.org platform still bothers your. Then why
don't you want to take part?


--
Ruvim

[dxf]

Post by dxf

...

Post by dxf
Their role on the TC is to ensure
nothing jeopardizes their investment.  It's impossible to have spent
20 years 'standardizing' and have achieved so little.

This critics is absolutely fruitless. No one owes you to develop any specifications unless you pay for it. Whether some people have achieved much or little is their own business.

When the ANS-TC sat, they did consider it their business and priority.

And what?  Anybody can claim that.

Not many can back it up with a 200+ page technical document.

Post by dxf
I've made that choice.

It seems, despite your choice, the Forth standardization process that is based on the forth-standard.org platform still bothers your. 

Why do I talk about the Standard? It's kind of unavoidable in technical
discussions when forthers have been suckled on it.

Then why don't you want to take part?

Perhaps because I've seen your success rate :)

[Ruvim]

Post by dxf

Post by dxf

Post by Ruvim
...

Post by dxf
Their role on the TC is to ensure
nothing jeopardizes their investment.  It's impossible to have spent
20 years 'standardizing' and have achieved so little.

This critics is absolutely fruitless. No one owes you to develop
any specifications unless you pay for it. Whether some people have
achieved much or little is their own business.

When the ANS-TC sat, they did consider it their business and priority.

And what?  Anybody can claim that.

Not many can back it up with a 200+ page technical document.

Post by dxf
I've made that choice.

It seems, despite your choice, the Forth standardization process that

is based on the forth-standard.org platform still bothers your.
Why do I talk about the Standard? It's kind of unavoidable in technical
discussions when forthers have been suckled on it.

It's okay to talk about the standard and the standardization process
(how to make them better), to talk about what you would like to see in
the standard, or what you think should be destandardized.

But critics about how much time something took, or how much personal
time participants devote to this activity is nonsense.

Post by dxf

Then why don't you want to take part?

Perhaps because I've seen your success rate :)

If you share my position, you could help me to convince other )

The standardization process cannot move forward without reaching
consensus at every step. To reach consensus, we should convince other
participants that some change or new thing worth standardizing. And we
should find/use many different constructive arguments for that.


--
Ruvim

[Ruvim]

On 2024-09-18 14:16, dxf wrote:
[...]

Post by dxf
When the ANS-TC sat, they did consider it their business and priority.
They knew the world wasn't going to wait.
Perhaps the situation has changed and now it's only fans the TC need worry about.

Who did TC needed to worry about before the situation has changed? The
professionals who make money? Because what?


--
Ruvim

[Ruvim]

Post by Anthony Howe

Post by Ruvim

Post by minforth
I would like to see an "officially recognized" standard reference
system, speed and number of xt's per word are of no importance.
Are you planning to make one?

I think, having the single standard reference implementation is a big
step back in Forth standardization process. Because implementation
details of the particular implementation will be used as requirements.

I think it should be recognised in some capacity, given Forth's origins,
but whether there should be a reference implementation probably not.

Post by Ruvim
I think, the standard conformance test suite is enough.

* incomplete
* as published in draft 19-1 has typos and possible errors
* test cases often test multiple words at once that have not be tested separately
* assumes the entire draft with all the optional sets are present,
rather than separate the word sets into separate unit tests

There is another testsuite:
https://github.com/gerryjackson/forth2012-test-suite


I have an idea for a testsuite that:
— is a ready-to-use program;
— does not use words from optional word sets (for that, all the
source files are transpiled into a single file that can be passed to stdin);
— does not change the host Forth system (for example, does not add
the missed standard words);
— has an external program that parses output of the testsuite from
the host's Forth system stdout and generates a report in text/xml/xhtml
form;
— includes into the report general information such as implemented
words and word sets, implementation options (that can be inferred by a
standard program), the behavior of some words in edge cases, etc., along
with the lists of passed and failed tests;
— has a configuration for a number of known systems (that is extended
by the community);

Post by Anthony Howe

Post by Ruvim
For illustrative purposes, we can have several different
implementations of Forth in Forth.

If there is reference implementation(s) I think it would be interesting
to have two: `single-xt` and `dual-xt` to demonstrate that both models
worth and are conforming.

Yes, that would be good.


--
Ruvim

[Gerry Jackson]

Post by Ruvim

Post by Anthony Howe

Post by Ruvim

Post by minforth
I would like to see an "officially recognized" standard reference
system, speed and number of xt's per word are of no importance.
Are you planning to make one?

I think, having the single standard reference implementation is a big
step back in Forth standardization process. Because implementation
details of the particular implementation will be used as requirements.

I think it should be recognised in some capacity, given Forth's
origins, but whether there should be a reference implementation
probably not.

Post by Ruvim
I think, the standard conformance test suite is enough.

* incomplete
* as published in draft 19-1 has typos and possible errors
* test cases often test multiple words at once that have not be tested separately
* assumes the entire draft with all the optional sets are present,
rather than separate the word sets into separate unit tests

https://github.com/gerryjackson/forth2012-test-suite

Just to put the record straight, The Forth Test suite in the Forth 200X
standard draft 19.1 incorporates most of my test suite with the addition
of, for example, tests for new words such as FIND-NAME and FIND-NAME-IN.

Post by Ruvim
  — is a ready-to-use program;
  — does not use words from optional word sets (for that, all the
source files are transpiled into a single file that can be passed to stdin);
  — does not change the host Forth system (for example, does not add
the missed standard words);
  — has an external program that parses output of the testsuite from
the host's Forth system stdout and generates a report in text/xml/xhtml
form;
  — includes into the report general information such as implemented
words and word sets, implementation options (that can be inferred by a
standard program), the behavior of some words in edge cases, etc., along
with the lists of passed and failed tests;
  — has a configuration for a number of known systems (that is extended
by the community);

Some of these, particularly the reporting has been suggested before but,
as you pointed out elsewhere everybody is an unpaid volunteer and nobody
has found the time or motivation to undertake such extensions. Are you
volunteering? I've just requested that the Forth 200X committee find
someone else to take over my test suite - so feel free to volunteer.

One thing not included in the Test Suite in the standard, as far as I
can see, and not mentioned in your wish list is that the Hayes tester
assumes so much of the system is working before the tests actually start
- how do you test the tester? I thought about this and developed a
preliminary test based on the assumption that for automated testing at
least the interpreter must work. So it starts by using SOURCE TYPE (
comments ) and CR to output messages and include a commentary of how the
tests progress. If the displays are correct it tests >IN manipulation
and uses it as an interpretive IF to actually detect errors. Then it
goes on to do a basic test of the words used in the Hayes tester and so
on. This is included in the link above.

[a***@spenarnc.xs4all.nl]

In article <vcfevo$6m9q$***@dont-email.me>,
Gerry Jackson <do-not-***@swldwa.uk> wrote:
<SNIP>

Post by Gerry Jackson
Some of these, particularly the reporting has been suggested before but,
as you pointed out elsewhere everybody is an unpaid volunteer and nobody
has found the time or motivation to undertake such extensions. Are you
volunteering? I've just requested that the Forth 200X committee find
someone else to take over my test suite - so feel free to volunteer.
One thing not included in the Test Suite in the standard, as far as I
can see, and not mentioned in your wish list is that the Hayes tester
assumes so much of the system is working before the tests actually start
- how do you test the tester? I thought about this and developed a
preliminary test based on the assumption that for automated testing at
least the interpreter must work. So it starts by using SOURCE TYPE (
comments ) and CR to output messages and include a commentary of how the
tests progress. If the displays are correct it tests >IN manipulation
and uses it as an interpretive IF to actually detect errors. Then it
goes on to do a basic test of the words used in the Hayes tester and so
on. This is included in the link above.

Practically speaking. ciforth went from a working fig-forth 16 bits i86
to a working 386 to a working ISO Forth to linux 32 and 64 i86
and linux 32 and 64 arm , to a linux 64 risc-V.
What you describe is worthwhile, but not needed in most cases.
A c-based compiler like gforth will most likely work essentially
on the first try.

(Appreciate your work on extending the tests.)

Post by Gerry Jackson
--
Gerry

[Ruvim]

Post by Gerry Jackson

Post by Ruvim

Post by Anthony Howe

Post by Ruvim

Post by minforth
I would like to see an "officially recognized" standard reference
system, speed and number of xt's per word are of no importance.
Are you planning to make one?

I think, having the single standard reference implementation is a
big step back in Forth standardization process. Because
implementation details of the particular implementation will be used
as requirements.

I think it should be recognised in some capacity, given Forth's
origins, but whether there should be a reference implementation
probably not.

Post by Ruvim
I think, the standard conformance test suite is enough.

* incomplete
* as published in draft 19-1 has typos and possible errors
* test cases often test multiple words at once that have not be tested separately
* assumes the entire draft with all the optional sets are present,
rather than separate the word sets into separate unit tests

https://github.com/gerryjackson/forth2012-test-suite

Just to put the record straight, The Forth Test suite in the Forth 200X
standard draft 19.1 incorporates most of my test suite with the addition
of, for example, tests for new words such as FIND-NAME and FIND-NAME-IN.

Post by Ruvim
   — is a ready-to-use program;
   — does not use words from optional word sets (for that, all the
source files are transpiled into a single file that can be passed to stdin);
   — does not change the host Forth system (for example, does not add
the missed standard words);
   — has an external program that parses output of the testsuite from
the host's Forth system stdout and generates a report in text/xml/
xhtml form;
   — includes into the report general information such as implemented
words and word sets, implementation options (that can be inferred by a
standard program), the behavior of some words in edge cases, etc.,
along with the lists of passed and failed tests;
   — has a configuration for a number of known systems (that is
extended by the community);

Some of these, particularly the reporting has been suggested before but,
as you pointed out elsewhere everybody is an unpaid volunteer and nobody
has found the time or motivation to undertake such extensions. Are you
volunteering? I've just requested that the Forth 200X committee find
someone else to take over my test suite - so feel free to volunteer.

I want to spend some time on such a testsuite. I even created a PoC to
filter out the output of the testsuite (I can create a public Git
repository for review now is anyone is interested). But at the moment I
have some higher priority tasks regarding the standardization process
than continue to develop the testsuite.

Post by Gerry Jackson
One thing not included in the Test Suite in the standard, as far as I
can see,  and not mentioned in your wish list is that the Hayes tester
assumes so much of the system is working before the tests actually start

I don't think that all the source codes of a testsuite should be
included into the standard text. It is enough that the standard contains
tests for all words and some of their combinations (as it is now). There
is no need to even include a definition for `t{` — it is enough to
describe the notation that is used for the test cases.

Post by Gerry Jackson
- how do you test the tester? I thought about this and developed a
preliminary test based on the assumption that for automated testing at
least the interpreter must work. So it starts by using SOURCE TYPE
( comments ) and CR to output messages and include a commentary of how
the tests progress. If the displays are correct it tests >IN
manipulation and uses it as an interpretive IF to actually detect
errors. Then it goes on to do a basic test of the words used in the
Hayes tester and so on. This is included in the link above.

It's good enough, I think.


We can try to use some *very* small amount of words to implement the
testsuite engine itself (for example, we can even avoid using the
control-flow words from the host system). But this will significantly
impact performance. I do not sure that this approach is worth implementing.

It seems, there is a *very* small chance that the testsuite will produce
false positive or false negative results due to bugs in some words of
the host Forth system and then terminate normally. It is much more
likely that the testsuite will be aborted during loading/compilation, or
will halt/hang and be interrupted by an external watchdog in such a case.


--
Ruvim

[a***@spenarnc.xs4all.nl]

Post by Ruvim
I don't think that all the source codes of a testsuite should be
included into the standard text. It is enough that the standard contains
tests for all words and some of their combinations (as it is now). There
is no need to even include a definition for `t{` — it is enough to
describe the notation that is used for the test cases.

I'm with you here. The test specification is what matters.

I use REGRESS that is left in place in the source.
If you hate this notation, or do not care to implement it,
it is still useful.
You can do
: REGRESS POSTPONE \ ;
and actually I do this if compiling to an executable.

Example:
REGRESS "aap noot mies " "noot" SEARCH ROT NIP S: TRUE 5

Now you can do the test by hand, copying and pasting the
part between REGRESS and S: and inspect the result.

<SNIP>

Post by Ruvim
It seems, there is a *very* small chance that the testsuite will produce
false positive or false negative results due to bugs in some words of
the host Forth system and then terminate normally. It is much more
likely that the testsuite will be aborted during loading/compilation, or
will halt/hang and be interrupted by an external watchdog in such a case.

The tests for the transputer forth were so involved that once the test
harness was in place, there were no more bugs to be found.
(Catching exceptions in a string interpreted from a file included from
a block etc.)
The Hayes test is more of a practical tool to get a system up and running.
Especially useful to get at the corner cases.
Remember the wise words.
Testing can reveal the presence of bugs, not the absence thereof.

Post by Ruvim
--
Ruvim

[mhx]

Post by Ruvim
Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.

First define exactly the [new things] that can be done with an xt or an
nt.

What some of my customers tried is, by using standard words, associate
generated code sequences with an xt (nearly impossible), or infer an nt
from an xt (which is not 1-to-n [n>=3], and asymmetrical).

A limited/qualified guarantee for the nt-xt relationship can be useful.
Example: DEFER aa ' DROP IS aa allows to recover the nt "DROP" from
aa's DEFER@ and it is possible to disassemble linked lists of nt's.

-marcel

[Ruvim]

Post by mhx

Post by Ruvim
Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.

First define exactly the [new things] that can be done with an xt or an
nt.

These things are well known.

For "xt" — "compile,", "execute", "catch".

For "nt" — "name>" (classic), "name>interpret", "name>compile",
"name>string".

Also, "xt" and "nt" can be passed to the words that accept "x".



But it is irrelevant to my questions.

The single-xt approach was used in Forth systems long before Forth-94.
Should this approach be possible for a standard system?

There is a point of view (which I don't share) that it is impossible to
implement the standard word `s"` (from the File word set) in a standard
*program*. I.e., that the following definition for `s"` is not standard
compliant:

: s" ( "ccc" -- sd | )
[char] " parse
state @ if postpone sliteral exit then
dup >r allocate throw tuck r@ move r>
; immediate

This effectively means that the classic single-xt approach is impossible
for a standard system.

Post by mhx
What some of my customers tried is, by using standard words, associate
generated code sequences with an xt (nearly impossible),
or infer an nt from an xt (which is not 1-to-n [n>=3], and asymmetrical).

Even in some classic single-xt systems, one xt can be associated with
many nt. (of course, what is now "nt" was known as "NFA").

Post by mhx
A limited/qualified guarantee for the nt-xt relationship can be useful.
Example: DEFER aa  ' DROP IS aa  allows to recover the nt "DROP" from

You probably mean the *xt* "DROP" from aa's DEFER@

DEFER aa
' DROP IS aa
' aa DEFER@ \ gives xt of DROP

Of cause, a standard program cannot disassemble linked lists of nt's


--
Ruvim

[minforth]

I hope that you are not trying to revive that dead old horse of
state-smartness.

There are already single-xt solutions to circumvent the poorly
designed specifications of ' and POSTPONE e.g. use different
wordlists for interpretation and compilation.

[Ruvim]

Post by minforth
I hope that you are not trying to revive that dead old horse of
state-smartness.

Different people understand different things by "state-smartness".
For some people the word "evaluate" is state smart, for other — not.

So, it is unclear what do you mean.

Post by minforth
There are already single-xt solutions to circumvent the poorly
designed specifications of ' and POSTPONE e.g. use different
wordlists for interpretation and compilation.

Do you mean https://github.com/uho/interpretive ?

This solution implies that two nt are associated with some words (what
violates my initial point).

This solution implies a single word list for all unordinary words. It is
not suitable for programs that use many word lists.

Post by minforth
the poorly designed specifications of ' and POSTPONE

POSTPONE is perfectly specified. What you dislike with it?



--
Ruvim

[a***@spenarnc.xs4all.nl]

Post by Ruvim

Post by minforth
I hope that you are not trying to revive that dead old horse of
state-smartness.

Different people understand different things by "state-smartness".
For some people the word "evaluate" is state smart, for other — not.
So, it is unclear what do you mean.

Post by minforth
There are already single-xt solutions to circumvent the poorly
designed specifications of ' and POSTPONE e.g. use different
wordlists for interpretation and compilation.

Do you mean https://github.com/uho/interpretive ?
This solution implies that two nt are associated with some words (what
violates my initial point).
This solution implies a single word list for all unordinary words. It is
not suitable for programs that use many word lists.

Post by minforth
the poorly designed specifications of ' and POSTPONE

POSTPONE is perfectly specified. What you dislike with it?

Also numbers (denotations) are state smart, but EVALUATE is also
a good point.

Post by Ruvim
--
Ruvim

[dxf]

Post by Ruvim
  : s" ( "ccc" -- sd | )
    [char] " parse
  ; immediate
This effectively means that the classic single-xt approach is impossible for a standard system.

Forth-94 section A.1.2 indicates the X3J14 Technical Committee were guided by
several considerations including:

"Cost of compliance
This goal includes such issues as common practice, how much existing code
would be broken by the proposed change, and the amount of effort required to
bring existing applications and systems into conformity with the Standard.

Utility
Be judged to have sufficiently essential functionality and frequency of use
to be deemed suitable for inclusion."

As 200x has since sought fit to require:

- a separate fp stack
- quote-delimited character interpretation ('A')
- S" support two interpretive buffers

nobody that has complied should be worried about excluding systems that use a
state-smart S" .

[Ruvim]

Post by dxf

Post by Ruvim
  : s" ( "ccc" -- sd | )
    [char] " parse
  ; immediate
This effectively means that the classic single-xt approach is impossible for a standard system.

Forth-94 section A.1.2 indicates the X3J14 Technical Committee were guided by
"Cost of compliance
This goal includes such issues as common practice, how much existing code
would be broken by the proposed change, and the amount of effort required to
bring existing applications and systems into conformity with the Standard.
Utility
Be judged to have sufficiently essential functionality and frequency of use
to be deemed suitable for inclusion."
- a separate fp stack
- quote-delimited character interpretation ('A')
- S" support two interpretive buffers

This does not exclude the classic single-xt approach.

Do you mean that these points do not meet the "Cost of Compliance" and
"Usefulness" considerations?

Post by dxf
nobody that has complied should be worried about excluding systems that use a
state-smart S" .

I do not understand how this follows from the above. My system complies
with the above points, and it is a single-xt system. Why I should not be
worried?

Moreover, excluding the single-xt approach does *nothing* useful for
programs.


--
Ruvim

[dxf]

Post by Ruvim

Post by dxf

   : s" ( "ccc" -- sd | )
     [char] " parse
   ; immediate
This effectively means that the classic single-xt approach is impossible for a standard system.

Forth-94 section A.1.2 indicates the X3J14 Technical Committee were guided by
  "Cost of compliance
   This goal includes such issues as common practice, how much existing code
   would be broken by the proposed change, and the amount of effort required to
   bring existing applications and systems into conformity with the Standard.
   Utility
   Be judged to have sufficiently essential functionality and frequency of use
   to be deemed suitable for inclusion."
- a separate fp stack
- quote-delimited character interpretation ('A')
- S" support two interpretive buffers

This does not exclude the classic single-xt approach.
Do you mean that these points do not meet the "Cost of Compliance" and "Usefulness" considerations?

IMO small systems are better off with Forth-94. And if they're doing that
they'll be free to implement things actually useful to them as the pressure
to conform has passed.

Post by Ruvim

Post by dxf
nobody that has complied should be worried about excluding systems that use a
state-smart S" .

I do not understand how this follows from the above. My system complies with the above points, and it is a single-xt system. Why I should not be worried?
Moreover, excluding the single-xt approach does *nothing* useful for programs.

Same for the items I listed. The real question is what major system still uses
single-xt and would object were it excluded.

[Anton Ertl]

Post by dxf
IMO small systems are better off with Forth-94.

Small systems pick and choose from standards as they see fit; they
ignore Forth-94 and Forth-2012 requirements in some places, but use
the standard as a guideline in places where compliance is compatible
with the requirements stemming from hardware limitations; in this
way the standard is useful even for those systems and their users.

The separate FP stack has not ever come up as an issue for small
systems that I ever heard of, probably because these systems tend not
to implement the optional Floating-Point wordset.

One example of non-compliance is the way DOES> is implemented on many
flash-based systems; in some systems it does not go with CREATE, but
with <BUILDS, and the use of multiple DOES> on the same word is not
supported.

- anton

[a***@spenarnc.xs4all.nl]

Post by Anton Ertl

Post by dxf
IMO small systems are better off with Forth-94.

Small systems pick and choose from standards as they see fit; they
ignore Forth-94 and Forth-2012 requirements in some places, but use
the standard as a guideline in places where compliance is compatible
with the requirements stemming from hardware limitations; in this
way the standard is useful even for those systems and their users.

There are other reasons to be elective. It is fine to have systems
available where everything is present, like gforth.
Small systems however have a place too, where only carefully selected
words are implemented, leaving a system that is a compromise between
being learnable and powerful. A library mechanism helps too.

Post by Anton Ertl
The separate FP stack has not ever come up as an issue for small
systems that I ever heard of, probably because these systems tend not
to implement the optional Floating-Point wordset.
One example of non-compliance is the way DOES> is implemented on many
flash-based systems; in some systems it does not go with CREATE, but
with <BUILDS, and the use of multiple DOES> on the same word is not
supported.

This is not even a choice in flash based systems. The noforth
model strives to use DOES> and has as little restrictions as
possible. In a many programs the DOES> pointer is filled in once.
If that pointer doesn't change it can be stored in flash.

Post by Anton Ertl
- anton

[dxf]

Post by Anton Ertl

Post by dxf
IMO small systems are better off with Forth-94.

Small systems pick and choose from standards as they see fit; they
ignore Forth-94 and Forth-2012 requirements in some places, but use
the standard as a guideline in places where compliance is compatible
with the requirements stemming from hardware limitations; in this
way the standard is useful even for those systems and their users.
The separate FP stack has not ever come up as an issue for small
systems that I ever heard of, probably because these systems tend not
to implement the optional Floating-Point wordset.
One example of non-compliance is the way DOES> is implemented on many
flash-based systems; in some systems it does not go with CREATE, but
with <BUILDS, and the use of multiple DOES> on the same word is not
supported.
- anton

The only guidance a standard can give is on duplicating the past. I see
no value in creating a new forth simply to do that. As an individual one
has the opportunity to bring something new that's not merely repetition.
At the very least one can avoid repeating the same mistakes.

[Anthony Howe]

Post by dxf
The only guidance a standard can give is on duplicating the past. I see
no value in creating a new forth simply to do that. As an individual one
has the opportunity to bring something new that's not merely repetition.
At the very least one can avoid repeating the same mistakes.

A standard does provide guidance and knowledge of the past, but also provides a
jump off point for new work, new designs, new blood.

In the 1980's there were a plethora C compilers (tiny c, small c, sozobon c, bsd
c, turbo c, watcom c, gnu c, sysv c, solaris, ...) just different enough to make
portability of source code a PITA. Similarly all the *nix variants drove a need
for POSIX and X/Open (now SUS) to improve portability of software (especially if
they wanted government contracts).

Linux came about and aimed for standards compliance in most aspects and then
built new and/or improved tools that extend beyond the standards. Now clang has
come on scene looking to dethrone the megalith gcc that is a bit of portability
nightmare within itself as it tries to support numerous CPUs and OSes.

Having an *agreed on* standard is a good thing, it helps new people learn what
is portable, see/hear of pitfalls, and _then_ improve (speed, size, supported
hardware) and extend. A standard should not get in the way of that, but help.

I read a large number of these posts about the woes of building a standard
and/or compliance - its like someone is trying to take away your favourite
teddy, "Mr.Floop", or washing your favourite blanky once a year.

I believe in standards and portability and there are those that sometimes need
to break with them because of special niche targets, but at least they that do
tend to know where they differ and document those differences.

[dxf]

...
I read a large number of these posts about the woes of building a standard and/or compliance - its like someone is trying to take away your favourite teddy, "Mr.Floop", or washing your favourite blanky once a year.

It looked to me the standard was being filled with "Mr.Floops" and favourite
teddys - this being the only way to force others to use them.

[dxf]

The only guidance a standard can give is on duplicating the past.  I see
no value in creating a new forth simply to do that.  As an individual one
has the opportunity to bring something new that's not merely repetition.
At the very least one can avoid repeating the same mistakes.

A standard does provide guidance and knowledge of the past, but also provides a jump off point for new work, new designs, new blood.
In the 1980's there were a plethora C compilers (tiny c, small c, sozobon c, bsd c, turbo c, watcom c, gnu c, sysv c, solaris, ...) just different enough to make portability of source code a PITA.  Similarly all the *nix variants drove a need for POSIX and X/Open (now SUS) to improve portability of software (especially if they wanted government contracts).
Linux came about and aimed for standards compliance in most aspects and then built new and/or improved tools that extend beyond the standards.  Now clang has come on scene looking to dethrone the megalith gcc that is a bit of portability nightmare within itself as it tries to support numerous CPUs and OSes.
Having an *agreed on* standard is a good thing, it helps new people learn what is portable, see/hear of pitfalls, and _then_ improve (speed, size, supported hardware) and extend.  A standard should not get in the way of that, but help.

There's no comparison between C and Forth. Good luck taking a credible application
written in SwiftForth and compiling it on VFX. Literally every app I write involves
a command-tail and a way to save it as a turnkey. There's not even a standard way
to do these basic things. So obviously lacking in pretentiousness has been the
standard one must ask whether there was ever a serious intent. At best it's a sparse
set of words that TC's have agreed you should have and even these have proven divisive
spawning decades of argument.

Maybe - just maybe - one could write a library routine with them but would one? Not
me. Why would I use anything as restricted as CASE or as broken as REPRESENT ?
There's a myriad of tiny useful tools lurking in every forth no standards committee
appears to have considered: /CHAR >DIGIT >CHAR MU* MU/MOD (.) /SIGN +STRING etc on the
grounds these can be defined portably. Sorry, I've no intention of going through the
nonsense of defining words I already have simply to give others the impression the
standard is useful.

If there's anything the standard has helped me learn is that I don't need it and
indeed better off without it.

[Ruvim]

Post by dxf

Post by Ruvim

Post by dxf

   : s" ( "ccc" -- sd | )
     [char] " parse
   ; immediate
This effectively means that the classic single-xt approach is impossible for a standard system.

Forth-94 section A.1.2 indicates the X3J14 Technical Committee were guided by
  "Cost of compliance
   This goal includes such issues as common practice, how much existing code
   would be broken by the proposed change, and the amount of effort required to
   bring existing applications and systems into conformity with the Standard.
   Utility
   Be judged to have sufficiently essential functionality and frequency of use
   to be deemed suitable for inclusion."
- a separate fp stack
- quote-delimited character interpretation ('A')
- S" support two interpretive buffers

This does not exclude the classic single-xt approach.
Do you mean that these points do not meet the "Cost of Compliance" and "Usefulness" considerations?

IMO small systems are better off with Forth-94. And if they're doing that
they'll be free to implement things actually useful to them as the pressure
to conform has passed.

Most words are optional. And even the CORE word set is not obligated for
a Standard System Subset.

The section "5.1.1 System compliance" of Forth-2012 says: "An otherwise
Standard System that provides only a portion of the Core words is a
Standard System Subset. An otherwise Standard System (Subset) that fails
to comply with one or more of the minimum values or ranges specified in
3 Usage requirements and its sub-sections has environmental restrictions."

The main pressure is that if a standard system provides a word in the
FORTH-WORDLIST with a standard name, that word shall behave as specified
in the standard. But this is a very light pressure, because if you do
not want to implement the standard behavior for a word, just give the
word another name, or place it in another word list.

Post by dxf

Post by Ruvim

Post by dxf
nobody that has complied should be worried about excluding systems that use a
state-smart S" .

I do not understand how this follows from the above. My system complies with the above points, and it is a single-xt system. Why I should not be worried?
Moreover, excluding the single-xt approach does *nothing* useful for programs.

Same for the items I listed.

It is not the same.

1) A separate fp stack makes programs far simpler comparing with
programs that comply the fp stack is separate or united with the data
stack, and moderately simpler than the programs with the environmental
dependency that the floating-point numbers are kept on the data stack.

NB: Keeping floating-point numbers on the data stack does not make a
Forth system non-standard, but it merely adds an environmental
restriction to this system, see the section "12.4.1.4 Environmental
restrictions" in Forth-2012.


2) Quote-delimited character interpretation ('A') makes programs
simpler, this seems obvious.


3) Two buffers for interpretive `s"` makes debugging simpler, because
you can test words like `rename-file` interactively, see "A.17.3.4 Other
transient regions" in Forth-2012.

Post by dxf
The real question is what major system still uses
single-xt and would object were it excluded.

It is not only the implementers of major systems who are allowed to object.


Some arguments:

- Most Forth systems are single-xt systems. Why we should reject them,
without any profit for programs?

- All standard programs are single-xt programs (in the part of
user-defined words). Why we should remove the way to document this
programs/words in the standard terms of interpretation semantics,
compilation semantics and execution semantics?



--
Ruvim

[Anton Ertl]

Post by Ruvim
- All standard programs are single-xt programs (in the part of
user-defined words). Why we should remove the way to document this
programs/words in the standard terms of interpretation semantics,
compilation semantics and execution semantics?

Who proposes removing that? I often write about the interpretatation
and compilation semantics of various words with default compilation
semantics or with immediate compilation semantics, and I see nobody
who wants to remove that possibility.

Examples:

: foo 1 ;

The execution semantics of FOO are to push 1 on the data stack.
The interpretation semantics of FOO are to push 1 on the data stack.
The compilation semantics of FOO are append the execution semantics of
FOO to the current definition.

: bar state @ ; immediate

The execution semantics of BAR are to push the contents of STATE on
the data stack.

The interpretation semantics of BAR are to push the contents of STATE
on the data stack.

The compilation semantics of BAR are to push the contents of STATE on
the data stack.

With that we can then determine what code like

: bla postpone bar ; immediate
bla . \ prints 0
] bla [ . \ prints -1

should do; I show the output in comments. I just tested gforth,
iforth, SwiftForth, and VFX Forth, and unsurprisingly they all produce
the output shown in the comments.

- anton

[Ruvim]

Post by Anton Ertl

Post by Ruvim
- All standard programs are single-xt programs (in the part of
user-defined words). Why we should remove the way to document this
programs/words in the standard terms of interpretation semantics,
compilation semantics and execution semantics?

Who proposes removing that? I often write about the interpretatation
and compilation semantics of various words with default compilation
semantics or with immediate compilation semantics, and I see nobody
who wants to remove that possibility.
: foo 1 ;
The execution semantics of FOO are to push 1 on the data stack.
The interpretation semantics of FOO are to push 1 on the data stack.
The compilation semantics of FOO are append the execution semantics of
FOO to the current definition.
The execution semantics of BAR are to push the contents of STATE on
the data stack.

Do you agree that this describes an observable behavior, not an
implementation? And all the implementations for execution semantics
that show this behavior are observationally equivalent to each other?

For example, this definition:

: bar2 state @ if state @ else 0 then ; immediate

is observationally equivalent to your `bar`.

Post by Anton Ertl
The interpretation semantics of BAR are to push the contents of STATE
on the data stack.

I think, we should use the black box model — specify what can be
observed. And according to what can be observed, the interpretation
semantics of this word are to push zero on the data stack. *All*
implementations for interpretation semantics that show this behavior are
observationally equivalent to each other. The same black box argument
applies to compilation semantics too. See bellow.

Post by Anton Ertl
The compilation semantics of BAR are to push the contents of STATE on
the data stack.

Anton, forgive me for being blunt, but I think your understanding of
"interpretation semantics" and "compilation semantics" for words whose
execution semantics depend on STATE is useless both in practice and in
theory.


Take a look at my next rationale.

When I'm interested in the interpretation semantics of a word, I'm
interested in precisely the behavior that can be *observed* when the
Forth text interpreter encounters the name of this word in
interpretation state. And if I specify the interpretation semantics for
a word, I specify namely this behavior. And if I want to perform the
interpretation semantics for a word, I want to perform namely this
behavior. And there are no exceptions to this!

If we say that the term "interpretation semantics" means something else
in some cases, we should introduce another term to denote the behavior
that can be observed when the Forth text interpreter encounters the name
of a word in interpretation state.

But in fact we don't need the term "interpretation semantics" for
anything else [1]. Nobody has given any rationale for that.

Then, why do we need to introduce *another* term? Let us always use the
term "interpretation semantics" in exactly this meaning.

The same applies to the term "compilation semantics".

Post by Anton Ertl
With that we can then determine what code like
: bla postpone bar ; immediate
bla . \ prints 0
] bla [ . \ prints -1
should do; I show the output in comments. I just tested gforth,
iforth, SwiftForth, and VFX Forth, and unsurprisingly they all produce
the output shown in the comments.

[1] Well, I can see only one reason for using another meaning for the
"interpretation semantics" and "compilation semantics" terms than given
above: to represent the classic implementation of `postpone` as
conforming to what is formally specified in Forth-94, without accepting
into the standard the proposed ambiguous condition (see [2]). But it is
better to honestly say that "postpone" appends execution semantics of
the word if this word is an immediate word. There is no need to blur the
meaning of terms.

[2] https://github.com/ForthHub/discussion/discussions/103#sect.excusing



--
Ruvim

[Anton Ertl]

Post by Ruvim

Post by Anton Ertl

Post by Ruvim
- All standard programs are single-xt programs (in the part of
user-defined words). Why we should remove the way to document this
programs/words in the standard terms of interpretation semantics,
compilation semantics and execution semantics?

Who proposes removing that? I often write about the interpretatation
and compilation semantics of various words with default compilation
semantics or with immediate compilation semantics, and I see nobody
who wants to remove that possibility.
: foo 1 ;
The execution semantics of FOO are to push 1 on the data stack.
The interpretation semantics of FOO are to push 1 on the data stack.
The compilation semantics of FOO are append the execution semantics of
FOO to the current definition.
The execution semantics of BAR are to push the contents of STATE on
the data stack.

Do you agree that this describes an observable behavior, not an
implementation? And all the implementations for execution semantics
that show this behavior are observationally equivalent to each other?
is observationally equivalent to your `bar`.

Yes. So what?

Post by Ruvim

Post by Anton Ertl
The interpretation semantics of BAR are to push the contents of STATE
on the data stack.

I think, we should use the black box model — specify what can be
observed. And according to what can be observed, the interpretation
semantics of this word are to push zero on the data stack.

No.

: [execute] execute ; immediate
s" bar" find-name name>interpret ] [execute] [ . \ prints -1

Use FIND-NAME or FIND-NAME-IN based on TRAVERSE-WORDLIST if the system
at hand does not implement FIND-NAME yet.

Post by Ruvim

Post by Anton Ertl
The compilation semantics of BAR are to push the contents of STATE on
the data stack.

Anton, forgive me for being blunt, but I think your understanding of
"interpretation semantics" and "compilation semantics" for words whose
execution semantics depend on STATE is useless both in practice and in
theory.

It's very useful, in particular for predicting how a system behaves.
I leave it up to you whether you consider this theory or practice.

Post by Ruvim
Take a look at my next rationale.
When I'm interested in the interpretation semantics of a word, I'm
interested in precisely the behavior that can be *observed* when the
Forth text interpreter encounters the name of this word in
interpretation state. And if I specify the interpretation semantics for
a word, I specify namely this behavior.

Now coming back from wishful thinking to reality, that's not how
systems behave.

Post by Ruvim
If we say that the term "interpretation semantics" means something else
in some cases, we should introduce another term to denote the behavior
that can be observed when the Forth text interpreter encounters the name
of a word in interpretation state.

It's the other way 'round: The standard specifies the interpretation
semantics and compilation semantics of words (either explicitly, or
through default mechanisms), and the text interpreter then performs
the interpretation semantics when it encounters the word in interpret
state, and it performs the compilation semantics when it encounters
the word in compilation state.

In the example above, the standard specifies unambiguously how the
execution semantics of BAR derives from STATE and @, and how the
interpretation semantics and compilation semantics of BAR are derived
from the execution semantics of BAR.

Post by Ruvim

Post by Anton Ertl
With that we can then determine what code like
: bla postpone bar ; immediate
bla . \ prints 0
] bla [ . \ prints -1
should do; I show the output in comments. I just tested gforth,
iforth, SwiftForth, and VFX Forth, and unsurprisingly they all produce
the output shown in the comments.

[1] Well, I can see only one reason for using another meaning for the
"interpretation semantics" and "compilation semantics" terms than given
above: to represent the classic implementation of `postpone` as
conforming to what is formally specified in Forth-94, without accepting
into the standard the proposed ambiguous condition (see [2]). But it is
better to honestly say that "postpone" appends execution semantics of
the word if this word is an immediate word. There is no need to blur the
meaning of terms.

The meaning of the compilation semantics of BAR is crystal-clear, and
likewise the interpretation semantics of BLA and the compilation
semantics of BLA. There is nothing blurred here.

As to the definition of POSTPONE, it is very straightforward, and
every system implements it correctly. No need for a redefinition.

They may not be what you wish for, but they are clearly defined.

- anton

[Ruvim]

Well, I still haven't convinced you, you haven't convinced me.
So, just two questions below.

[...]
[...]

Post by Anton Ertl

Post by Ruvim

Post by Anton Ertl
The interpretation semantics of BAR are to push the contents of STATE
on the data stack.

I think, we should use the black box model — specify what can be
observed. And according to what can be observed, the interpretation
semantics of this word are to push zero on the data stack.

No.
: [execute] execute ; immediate
s" bar" find-name name>interpret ] [execute] [ . \ prints -1

Could you please formulate: how to programmatically perform the behavior
that can be observed when the Forth text interpreter encounters the name
of your word "bar" in interpretation state?

And how to do it in the general case (for any defined word)?


--
Ruvim

[Ruvim]

Post by Ruvim
[...]

Post by Anton Ertl

Post by Ruvim

Post by Anton Ertl
The interpretation semantics of BAR are to push the contents of STATE
on the data stack.

I think, we should use the black box model — specify what can be
observed. And according to what can be observed, the interpretation
semantics of this word are to push zero on the data stack.

No.
: [execute] execute ; immediate
s" bar" find-name name>interpret ] [execute] [ . \ prints -1

Could you please formulate: how to programmatically perform the behavior
that can be observed when the Forth text interpreter encounters the name
of your word "bar" in interpretation state?
And how to do it in the general case (for any defined word)?

I also want to address these questions to everyone.

Can you suggest one ore more standard-compliant ways to exhibit the same
behavior that is observed when the Forth text interpreter encounters the
name of the word "bar" (defined above) in interpretation state?

You may provide quotations (or anonymous definitions), execution of
which exhibits that behavior.

And also, if you can, suggest such ways for any word "foo", regardless
how it is defined.



--
Ruvim

[a***@spenarnc.xs4all.nl]

In article <vcpi98$25spg$***@dont-email.me>,
Ruvim <***@gmail.com> wrote:
<SNIP>

Post by Ruvim
2) Quote-delimited character interpretation ('A') makes programs
simpler, this seems obvious.
3) Two buffers for interpretive `s"` makes debugging simpler, because
you can test words like `rename-file` interactively, see "A.17.3.4 Other
transient regions" in Forth-2012.

I hate those two. Requiring an arbitrary number of buffers for s"
(like 2). 'A' requires a special provision in number handling.
I don't like overloading ' .

Post by Ruvim
Ruvim

Groetjes Albert

[Ruvim]

Post by a***@spenarnc.xs4all.nl
<SNIP>

Post by Ruvim
2) Quote-delimited character interpretation ('A') makes programs
simpler, this seems obvious.
3) Two buffers for interpretive `s"` makes debugging simpler, because
you can test words like `rename-file` interactively, see "A.17.3.4 Other
transient regions" in Forth-2012.

I hate those two. Requiring an arbitrary number of buffers for s"
(like 2). 'A' requires a special provision in number handling.
I don't like overloading ' .

You say this from the point of view of a system implementer. I don't see
any objections on the merits.

Those two make use of Forth simpler in programs. Do you have any counter
arguments?


--
Ruvim

[a***@spenarnc.xs4all.nl]

Post by Ruvim

Post by a***@spenarnc.xs4all.nl
<SNIP>

Post by Ruvim
2) Quote-delimited character interpretation ('A') makes programs
simpler, this seems obvious.
3) Two buffers for interpretive `s"` makes debugging simpler, because
you can test words like `rename-file` interactively, see "A.17.3.4 Other
transient regions" in Forth-2012.

I hate those two. Requiring an arbitrary number of buffers for s"
(like 2). 'A' requires a special provision in number handling.
I don't like overloading ' .

You say this from the point of view of a system implementer. I don't see
any objections on the merits.
Those two make use of Forth simpler in programs. Do you have any counter
arguments?

At first sight, no.

An argument that doesn't cut it, that I think Forth is not well
designed in the first place, and we are adding ornaments that make
Forth like a Christmas tree.

Post by Ruvim
--
Ruvim

Groetjes Albert

[minforth]

Post by a***@spenarnc.xs4all.nl
An argument that doesn't cut it, that I think Forth is not well
designed in the first place, and we are adding ornaments that make
Forth like a Christmas tree.

For this reason, I don't like major extensions to the
standard. There would be a lot to ‘improve’ or add, but
a standard is not a Forth system and not an application.

A standard is just a paper that describes the minimum
requirements for a minimum set of commands/words. The
'users' of this standard can label their product as
ANSI/ISO compliant.

If the standard is tightened, there will be fewer
compliant systems. That would be just another nail
in the coffin.

[dxf]

Post by Ruvim

Post by dxf
...
Same for the items I listed.

It is not the same.
1) A separate fp stack makes programs far simpler comparing with programs that comply the fp stack is separate or united with the data stack, and moderately simpler than the programs with the environmental dependency that the floating-point numbers are kept on the data stack.
NB: Keeping floating-point numbers on the data stack does not make a Forth system non-standard, but it merely adds an environmental restriction to this system, see the section "12.4.1.4 Environmental restrictions" in Forth-2012.

I hadn't seen that. Forth-94 stated floating-point stack was "the default".
If the only change is that the latter is clarified, then no harm done.
Implementing separate stack on an 8-bit cpu would be expensive and a
performance killer. As to being "far simpler" to program, similar appeals
are made in respect of locals. I make it a point to program as if I had a
unified stack just to see if the claim is true.

Post by Ruvim
2) Quote-delimited character interpretation ('A') makes programs simpler, this seems obvious.

Only thing obvious is it's an import from other languages and redundant.
Forth Inc stated they didn't agree with it but eventually provided it.

Post by Ruvim
3) Two buffers for interpretive `s"` makes debugging simpler, because you can test words like `rename-file` interactively, see "A.17.3.4 Other transient regions" in Forth-2012.

I have >PAD ( adr u -- adr2 u ) for that. Uses existing resources and is
more flexible.

Post by Ruvim

Post by dxf
The real question is what major system still uses
single-xt and would object were it excluded.

It is not only the implementers of major systems who are allowed to object.

Only ones in a position to mount a challenge.

[Ruvim]

...

Post by dxf

Post by Ruvim
NB: Keeping floating-point numbers on the data stack does not make a Forth system non-standard, but it merely adds an environmental restriction to this system, see the section "12.4.1.4 Environmental restrictions" in Forth-2012.

I hadn't seen that. Forth-94 stated floating-point stack was "the default".
If the only change is that the latter is clarified, then no harm done.
Implementing separate stack on an 8-bit cpu would be expensive and a
performance killer.
As to being "far simpler" to program, similar appeals
are made in respect of locals.
I make it a point to program as if I had a
unified stack just to see if the claim is true.

A real problem was to create programs that work with floating point
numbers and would work correctly both on a unified fp stack and on a
separate fp stack.

See the section "C.7.2 Separate Floating-point Stack is now Standard" in
Forth-2012 <https://forth-standard.org/standard/diff#subsection.C.7.2>

Post by dxf

Post by Ruvim
2) Quote-delimited character interpretation ('A') makes programs simpler, this seems obvious.

Only thing obvious is it's an import from other languages and redundant.
Forth Inc stated they didn't agree with it but eventually provided it.

Using `'x'` is simpler and shorter than `[char] x` or `char x` depending
on the context.

And even if you redefine `[char]` to provide the expected interpretation
semantics, like:

: [char] state @ if postpone [char] else char then ; immediate

`[char] x` is still longer than `'x'` and provides no additional benefit
to programs.

Post by dxf

Post by Ruvim
3) Two buffers for interpretive `s"` makes debugging simpler, because you can test words like `rename-file` interactively, see "A.17.3.4 Other transient regions" in Forth-2012.

I have >PAD ( adr u -- adr2 u ) for that. Uses existing resources and is
more flexible.

The phrase:

s" foo" s" bar" rename-file .

is simpler than:

s" foo" >pad s" bar" rename-file .

What advantages does the latter provide to users over the former?



If a Forth system is so limited in memory that it cannot provide two
buffers for `s"`, it *might* provide only one buffer and declare the
corresponding environmental restriction according to the sections:

- 5.1.1 System compliance
| An otherwise Standard System (Subset) that fails to comply
| with one or more of the minimum values or ranges specified
| in "3 Usage requirements" and its sub-sections has
| environmental restrictions.

- 5.1.2 System labeling
| The phrase "with Environmental Restrictions" shall be
| appended to the label of a Standard System (Subset) that
| has environmental restrictions.

- 11.3 Additional usage requirements, 11.3.4 Other transient regions
| The system provides transient buffers for `S"` and `S\"`
| regions strings. These buffers shall be no less than 80
| characters in length, and there shall be at least two buffers.




--
Ruvim

[dxf]

...

Post by Ruvim
NB: Keeping floating-point numbers on the data stack does not make a Forth system non-standard, but it merely adds an environmental restriction to this system, see the section "12.4.1.4 Environmental restrictions" in Forth-2012.

I hadn't seen that.  Forth-94 stated floating-point stack was "the default".
If the only change is that the latter is clarified, then no harm done.
Implementing separate stack on an 8-bit cpu would be expensive and a
performance killer. 
As to being "far simpler" to program, similar appeals
are made in respect of locals.
I make it a point to program as if I had a
unified stack just to see if the claim is true.

A real problem was to create programs that work with floating point numbers and would work correctly both on a unified fp stack and on a separate fp stack.

Code written for a unified stack works on every system. The problem rather was
those hell-bent against a unified fp stack. It wasn't enough ANS permitted them
to write separate stack fp code. They wanted the unified stack fp gone - out of
the picture. In 2012 a separate fp stack isn't an option - it's a commandment:

12.3.3 Floating-point stack
...
The floating-point stack _shall_ be separate from the data and return stacks.

When the Bible said:

"You _shall_ have no other gods before Me"

there was no 'environmental restriction' in the footnotes allowing other gods or
none as that would render the commandment meaningless.

...
- 5.1.1 System compliance
| An otherwise Standard System (Subset) that fails to comply
| with one or more of the minimum values or ranges specified
| in "3 Usage requirements" and its sub-sections has
| environmental restrictions.
- 5.1.2 System labeling
| The phrase "with Environmental Restrictions" shall be
| appended to the label of a Standard System (Subset) that
| has environmental restrictions.
- 11.3 Additional usage requirements, 11.3.4 Other transient regions
| The system provides transient buffers for `S"` and `S\"`
| regions strings. These buffers shall be no less than 80
| characters in length, and there shall be at least two buffers.

This again is a mess since:

S" abc" S" def" S" ghi"

in a 'standard program' falls outside the minimum and would not be
considered portable. Yet a 'standard system' that cannot do:

S" abc" S" def" S" ghi"

is deemed by 2012 to have an 'environmental restriction' since:

11.3.4 Other transient regions
... "RAM-limited systems may have environmental restrictions on the
number of buffers and their lifetimes."

Both Forth-94 and 2012 define 'environmental restriction' as applying
to systems which 'cannot meet the minimum values set out in section 3'.

AFAICS 'two' is the minimum number of S" interpretive buffers specified
by 2012. Such a system should thus be considered entirely compliant.
OTOH a 'unified fp stack' is not any kind of minimum. Rather it ignores
12.3.3 in the provisioning of a separate fp stack. Such a system is
outright non-compliant.

[minforth]

Must be bad weather and boring where you live. ;-)
If you have a lot of strings to juggle, treat yourself
to a string stack. Forth is all about flexibility, right?

[mhx]

On Fri, 22 Nov 2024 10:11:48 +0000, minforth wrote:
[..]

Post by minforth
If you have a lot of strings to juggle, treat yourself
to a string stack. Forth is all about flexibility, right?

When parsing commands for my engineering tools, strings
are indispensable. But I use a ringbuffer, not a stack.

Nowadays I tend to use temporary redirection of I/O to
(large) strings with <$$ ... $$> ( -- c-addr u ). For
short sequences nothing beats $+ .

-marcel

[minforth]

Post by mhx
When parsing commands for my engineering tools, strings
are indispensable. But I use a ringbuffer, not a stack.

A ring buffer for holding strings is a classic for Forth
systems. For larger string sequences, such as data in XML
format, ring buffers tend to be overwritten. But that's
an application-sprecific implementation detail, not a
topic for a standard.

[mhx]

Post by minforth

Post by mhx
When parsing commands for my engineering tools, strings
are indispensable. But I use a ringbuffer, not a stack.

A ring buffer for holding strings is a classic for Forth
systems. For larger string sequences, such as data in XML
format, ring buffers tend to be overwritten. But that's
an application-sprecific implementation detail, not a
topic for a standard.

Ring buffers should manage their pool appropriately. That's
a quality of implementation aspect. Slightly more dangerous
is using their strings permanently. It assumes quality at
the other side of the keyboard.

-marcel

[dxf]

Post by minforth
Must be bad weather and boring where you live. ;-)

You're welcome :)

Post by minforth
If you have a lot of strings to juggle, treat yourself
to a string stack. Forth is all about flexibility, right?

A relative never cleaned their email inbox. For the last
month any message sent bounced with 'mailbox full'. Their
solution was to pay for a bigger inbox.

[a***@spenarnc.xs4all.nl]

Post by dxf

Post by minforth
Must be bad weather and boring where you live. ;-)

You're welcome :)

Post by minforth
If you have a lot of strings to juggle, treat yourself
to a string stack. Forth is all about flexibility, right?

A relative never cleaned their email inbox. For the last
month any message sent bounced with 'mailbox full'. Their
solution was to pay for a bigger inbox.

If you set aside 1 Gbyte of a 8 Gbyte for a circular string
stack, why don't you do like me? Permanently allocate all
strings in the dictionary. This is a so called memory leak,
but this is not so bad compared to wasting 1 Gbyte up front.
Works well together with MARKER, I'd see better than a circular
string set.

Groetjes Albert

[dxf]

Post by a***@spenarnc.xs4all.nl

Post by dxf

Post by minforth
Must be bad weather and boring where you live. ;-)

You're welcome :)

Post by minforth
If you have a lot of strings to juggle, treat yourself
to a string stack. Forth is all about flexibility, right?

A relative never cleaned their email inbox. For the last
month any message sent bounced with 'mailbox full'. Their
solution was to pay for a bigger inbox.

If you set aside 1 Gbyte of a 8 Gbyte for a circular string
stack, why don't you do like me? Permanently allocate all
strings in the dictionary. This is a so called memory leak,
but this is not so bad compared to wasting 1 Gbyte up front.
Works well together with MARKER, I'd see better than a circular
string set.

For systems that use a circular buffer to store temporary strings
the size is typically 1 or 2 Kb. That's reflected in the rather
vague spec for S" . AFAICS the 2012 decision was more about
implementing common practice than needing common practice. IMO
Forth-94 got the balance right for both S" and floating point stack.

[Stephen Pelc]

Post by Ruvim
There is a point of view (which I don't share) that it is impossible to
implement the standard word `s"` (from the File word set) in a standard
*program*. I.e., that the following definition for `s"` is not standard
: s" ( "ccc" -- sd | )
[char] " parse
; immediate
This effectively means that the classic single-xt approach is impossible
for a standard system.

The problem with definitions such as yours above is that they attempt to
solve the problem of words with "non-default compilation semantics"
(NDCS) using both immediacy and state-smart techniques.

There is nothing in the standard that says it has to be done that way.
The trouble is that the standard provides no tools to implement such
words. We (MPE) provide such tools in VFX Forth 64, which comes
with full source code.

If the standard removes the entitlement to have words such as S" a
significant portion of implementors will just ignore the standard, so reducing
its usefulness.

I suspect that some members of the TC only talk to each other, and have
little or no contact with people who disagree with them on fundamental
issues.

Stephen

[Ruvim]

Post by Stephen Pelc

Post by Ruvim
There is a point of view (which I don't share) that it is impossible to
implement the standard word `s"` (from the File word set) in a standard
*program*. I.e., that the following definition for `s"` is not standard
: s" ( "ccc" -- sd | )
[char] " parse
; immediate
This effectively means that the classic single-xt approach is impossible
for a standard system.

The problem with definitions such as yours above is that they attempt to
solve the problem of words with "non-default compilation semantics"
(NDCS) using both immediacy and state-smart techniques.

Why is this a problem? They were implemented only in this way before
cmForth (AFAIK).

Post by Stephen Pelc
There is nothing in the standard that says it has to be done that way.

Yes. It may be done in this way, as well as in other way.

Actually, the Forth-94 standard was intended to cover the classic
single-xt systems and cmForth. No other approaches were in use in 1993
(to my knowledge).

Post by Stephen Pelc
The trouble is that the standard provides no tools to implement such
words. We (MPE) provide such tools in VFX Forth 64, which comes
with full source code.
If the standard removes the entitlement to have words such as S" a
significant portion of implementors will just ignore the standard, so reducing
its usefulness.

Agreed.

Post by Stephen Pelc
I suspect that some members of the TC only talk to each other, and have
little or no contact with people who disagree with them on fundamental
issues.

What are the particular fundamental issues? And where can these people
be heard?


--
Ruvim

[Stephen Pelc]

Post by Ruvim

Post by Stephen Pelc
The trouble is that the standard provides no tools to implement such
words. We (MPE) provide such tools in VFX Forth 64, which comes
with full source code.
If the standard removes the entitlement to have words such as S" a
significant portion of implementors will just ignore the standard, so reducing
its usefulness.

Agreed.

The NDCS: notation in VFX provides a simplicity and clarity that is absent
from most other approaches that I have seen.

Post by Ruvim

Post by Stephen Pelc
I suspect that some members of the TC only talk to each other, and have
little or no contact with people who disagree with them on fundamental
issues.

What are the particular fundamental issues? And where can these people
be heard?

Mitch Bradley was particularly fervent in retaining state-smart words,
especially when defining Domain Specific Languages (DSLs).
He has a point, but the TC has been so fervent in its "state smart
words are evil" approach that he simply regards Open Firmware
as its own standard - another group lost to the current Forth
standard.

Does this matter? Yes, there are still OF projects at compaanies
like Apple.

It will be ineffective to assume that all this people will seek out
the Forth standards committee. It is up to the committee to
perform some research and talk sympathetically to people
who have given up on Forth standards. It's just practical
politics.

[Anton Ertl]

Post by Stephen Pelc

Post by Ruvim
What are the particular fundamental issues? And where can these people
be heard?

Mitch Bradley was particularly fervent in retaining state-smart words,
especially when defining Domain Specific Languages (DSLs).

Everything I read from him on the topic was that he likes interpretive
control structures, and that he has not experienced problems with
state-smart implementations of such words. Fervent?

Post by Stephen Pelc
He has a point, but the TC has been so fervent in its "state smart
words are evil" approach that he simply regards Open Firmware
as its own standard - another group lost to the current Forth
standard.

Mitch Bradley has been on the TC. It's interesting that you
characterize the TC as being 'fervent in its "state smart words are
evil" approach'; you were there, too. My impression used to be that
while both camps existed and their influence is visible in various
places in Forth-94, the intention was that at least words like S"
should be implementable as STATE-smart words, and that the fact that
the text of the standard does not reflect this intention is an
oversight. Is my impression wrong?

Post by Stephen Pelc
Does this matter? Yes, there are still OF projects at compaanies
like Apple.

Evidence? Certainly <https://apple.fandom.com/wiki/Open_Firmware> says:

|Starting in 2006, Apple phased out its use of Open Firmware in favor
|of EFI (Extensible Firmware Interface) during its transition to Intel
|processors.

So if Apple still uses Open Firmware, even Apple fans don't know about
it.

Oracle has canceled SPARC development in 2017, so that branch of Open
Firmware is dying, too.

So the only living branch of Open Firmware may be at IBM.

Post by Stephen Pelc
It will be ineffective to assume that all this people will seek out
the Forth standards committee. It is up to the committee to
perform some research and talk sympathetically to people
who have given up on Forth standards. It's just practical
politics.

Has anyone held you back from taking such efforts?

- anton

[a***@spenarnc.xs4all.nl]

Post by Stephen Pelc
Mitch Bradley was particularly fervent in retaining state-smart words,
especially when defining Domain Specific Languages (DSLs).
He has a point, but the TC has been so fervent in its "state smart
words are evil" approach that he simply regards Open Firmware
as its own standard - another group lost to the current Forth
standard.

I don't object keeping STATE smart words out of the standards, however
a standard committee has no business objecting to my using STATE smart
words in program.
I also have no scrupules using extensions in my own Forth
that can not be reproduced portably.

Post by Stephen Pelc
Does this matter? Yes, there are still OF projects at compaanies
like Apple.

Leaning extensibly on Open Source Forth is probably less
disadvantageous than relying on c-libraries.

Post by Stephen Pelc
It will be ineffective to assume that all this people will seek out
the Forth standards committee. It is up to the committee to
perform some research and talk sympathetically to people
who have given up on Forth standards. It's just practical
politics.
--

Groetjes Albert

[a***@spenarnc.xs4all.nl]

Post by Ruvim

Post by mhx

Post by Ruvim
Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.

First define exactly the [new things] that can be done with an xt or an
nt.

These things are well known.
For "xt" — "compile,", "execute", "catch".
For "nt" — "name>" (classic), "name>interpret", "name>compile",
"name>string".
Also, "xt" and "nt" can be passed to the words that accept "x".
But it is irrelevant to my questions.
The single-xt approach was used in Forth systems long before Forth-94.
Should this approach be possible for a standard system?
There is a point of view (which I don't share) that it is impossible to
implement the standard word `s"` (from the File word set) in a standard
*program*. I.e., that the following definition for `s"` is not standard
: s" ( "ccc" -- sd | )
[char] " parse
; immediate

/*****************************************************************************/
/* This is not true. */
/*****************************************************************************/

I have demonstrated that it is possible to make numbers state smart
(the excursion to S" serves only to muddy the waters) where
the definition of number or S" doesn't contain a reference to STATE.
STATE can be handled purely in INTERPRET. If a word in compilation mode
leaves something on the stack it is compiled as a literal.
[This supposes that the data stack is not used as a compilation stack ].

My approach to Forth is practical. Purisme like this serves no practical
purpose. (I'm not in the : >= < 0= ; crowd. ) and I have no intent
to implement it in my Forth (ciforth)
In this context you could POSTPONE a number with the intended effect,
without even thinking about it. (I'm opposed to POSTPONE, let alone
postponing numbers, but anyway.)
[ P.S. I am not as nervous as Anton Ertl about postponing state smart words.]

Post by Ruvim
This effectively means that the classic single-xt approach is impossible
for a standard system.

No!
It just means that you are hung up on traditional implementation methods.

Post by Ruvim

Post by mhx
What some of my customers tried is, by using standard words, associate
generated code sequences with an xt (nearly impossible),
or infer an nt from an xt (which is not 1-to-n [n>=3], and asymmetrical).

Even in some classic single-xt systems, one xt can be associated with
many nt. (of course, what is now "nt" was known as "NFA").

I cringe on this formulation. Several words can have the same
behaviour. These behaviours being the same is what counts.
Talking about xt's in this way ignores the severe problems you
get by ignoring whether or not a word (xt? nt? ) is a CREATE
word or not.

It all starts with the notion that you can separate the properties
of a word, then ignore the word itself. You talk about an x-coordinate
and ignore the point itself where it belongs too.

Post by Ruvim

Post by mhx
A limited/qualified guarantee for the nt-xt relationship can be useful.
Example: DEFER aa  ' DROP IS aa  allows to recover the nt "DROP" from

DEFER aa
' DROP IS aa
Of cause, a standard program cannot disassemble linked lists of nt's

Someone should be the boss. I propose the dea ("nt") as the boss.
You could get the xt (behaviour,"CFA") from the dea.
You couldn't get the point back from it x-coordinate.

Post by Ruvim
--
Ruvim

Groetjes Albert

[Ruvim]

Post by a***@spenarnc.xs4all.nl

Post by Ruvim

Post by mhx

Post by Ruvim
Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.

[...]

Post by a***@spenarnc.xs4all.nl

Post by Ruvim
The single-xt approach was used in Forth systems long before Forth-94.
Should this approach be possible for a standard system?
There is a point of view (which I don't share) that it is impossible to
implement the standard word `s"` (from the File word set) in a standard
*program*. I.e., that the following definition for `s"` is not standard
: s" ( "ccc" -- sd | )
[char] " parse
; immediate

/*****************************************************************************/
/* This is not true. */
/*****************************************************************************/
I have demonstrated that it is possible to make numbers state smart
(the excursion to S" serves only to muddy the waters) where
the definition of number or S" doesn't contain a reference to STATE.

It seems, you have misunderstood what I said. I have said "in a standard
*program*", not "in a standard system".

This is important for standard libraries that may need to define or
redefine some standard words. Here by standard library I mean a standard
program that, when loaded, does not make the standard system non-standard.

See also "4.2.2 Other program documentation", that says:
| A program shall also document:
| - whether a Standard System exists after the program is loaded.

Post by a***@spenarnc.xs4all.nl

Post by Ruvim

Post by mhx
What some of my customers tried is, by using standard words, associate
generated code sequences with an xt (nearly impossible),
or infer an nt from an xt (which is not 1-to-n [n>=3], and asymmetrical).

Even in some classic single-xt systems, one xt can be associated with
many nt. (of course, what is now "nt" was known as "NFA").

I cringe on this formulation.

This is what the standard says. Namely, the section "3.1.3.5 Execution
tokens" says: "Different definitions may have the same execution token
if the definitions are equivalent".

For example:

1 constant a
1 constant b
' a ' b = .

It is possible for a standard system to print "-1" when interpreting
this program.



[...]


--
Ruvim

[a***@spenarnc.xs4all.nl]

Post by Ruvim

Post by a***@spenarnc.xs4all.nl

Post by Ruvim

Post by mhx

Post by Ruvim
Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.

[...]

Post by a***@spenarnc.xs4all.nl

Post by Ruvim
The single-xt approach was used in Forth systems long before Forth-94.
Should this approach be possible for a standard system?
There is a point of view (which I don't share) that it is impossible to
implement the standard word `s"` (from the File word set) in a standard
*program*. I.e., that the following definition for `s"` is not standard

The double negation makes it hard to understand.
You are of the opinion that it is possible to implement s" in a standard program.
You mean that the following code is standard compliant.
You throw in the heap (ALLOCATE), that requires a powerful system, okay.
If you require SLITERAL ALLOCATE TUCK (that are not present e.g. in the
ciforth kernel) what is the probability that S" still has to be defined?
(In ciforth it is already defined).

Post by Ruvim

Post by a***@spenarnc.xs4all.nl

Post by Ruvim
: s" ( "ccc" -- sd | )
[char] " parse
; immediate

/*****************************************************************************/
/* This is not true. */
/*****************************************************************************/
I have demonstrated that it is possible to make numbers state smart
(the excursion to S" serves only to muddy the waters) where
the definition of number or S" doesn't contain a reference to STATE.

It seems, you have misunderstood what I said. I have said "in a standard
*program*", not "in a standard system".

I misunderstood it. In fact the longer I look, the less I understand.
Of course a number of standard words cannot be portably implemented.
That is a remark I have made myself. In this case you say that in
a Forth where an arbitrary set of difficult words are implemented
it is possible to define S" portably in terms of standard words.
So true.

If I add the condition that STATE is only used in INTERPRET,
that is cheating, and largely irrelevant.

Post by Ruvim
This is important for standard libraries that may need to define or
redefine some standard words. Here by standard library I mean a standard
program that, when loaded, does not make the standard system non-standard.

Agreed. However standard libraries are not useful in the context of
gforth where every imaginable word in the standard is present,
unless for the purpose of exactly defining meaning.
I remember Algol68 went that route. Most features are explained
in Algol68 itself, with the remark that the implementer should
think of more clever ways to do it. Is this similar?

Post by Ruvim
| - whether a Standard System exists after the program is loaded.

Post by a***@spenarnc.xs4all.nl

Post by Ruvim

Post by mhx
What some of my customers tried is, by using standard words, associate
generated code sequences with an xt (nearly impossible),
or infer an nt from an xt (which is not 1-to-n [n>=3], and asymmetrical).

Even in some classic single-xt systems, one xt can be associated with
many nt. (of course, what is now "nt" was known as "NFA").

I cringe on this formulation.

This is what the standard says. Namely, the section "3.1.3.5 Execution
tokens" says: "Different definitions may have the same execution token
if the definitions are equivalent".
1 constant a
1 constant b
' a ' b = .
It is possible for a standard system to print "-1" when interpreting
this program.

I have a hard time with this. I can't argue with the standard however.
"I cringe that this is in the standard."

Post by Ruvim
--
Ruvim

Groetjes Albert

[mhx]

[..]

Post by a***@spenarnc.xs4all.nl

Post by Ruvim
1 constant a
1 constant b
' a ' b = .
It is possible for a standard system to print "-1" when interpreting
this program.

I have a hard time with this. I can't argue with the standard however.
"I cringe that this is in the standard."

Why? 'a' and 'b' are user defined words, '=' is a standard word,
and 'true' is the expected outcome.

-marcel

[a***@spenarnc.xs4all.nl]

Post by mhx
[..]

Post by a***@spenarnc.xs4all.nl

Post by Ruvim
1 constant a
1 constant b
' a ' b = .
It is possible for a standard system to print "-1" when interpreting
this program.

I have a hard time with this. I can't argue with the standard however.
"I cringe that this is in the standard."

Why? 'a' and 'b' are user defined words, '=' is a standard word,
and 'true' is the expected outcome.

I expect false is the expected outcome.

Post by mhx
-marcel

[Anton Ertl]

Post by mhx
[..]

Post by Ruvim
1 constant a
1 constant b
' a ' b = .

...

Post by mhx
Why? 'a' and 'b' are user defined words, '=' is a standard word,
and 'true' is the expected outcome.

Are you sure?

[~:152648] iforth

FORTH> 1 constant a ok
FORTH> 1 constant b ok
FORTH> ' a ' b = . 0 ok

I actually know of no system that outputs -1.

- anton

[mhx]

On Mon, 23 Sep 2024 17:02:51 +0000, Anton Ertl wrote:
[..]

Post by Anton Ertl
[~:152648] iforth
FORTH> 1 constant a ok
FORTH> 1 constant b ok
FORTH> ' a ' b = . 0 ok
I actually know of no system that outputs -1.

A really aggressive optimizer could :-)

-marcel

[Ruvim]

Post by a***@spenarnc.xs4all.nl

Post by Ruvim

Post by a***@spenarnc.xs4all.nl

Post by Ruvim

Post by Ruvim
Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.

[...]

Post by a***@spenarnc.xs4all.nl

Post by Ruvim
The single-xt approach was used in Forth systems long before Forth-94.
Should this approach be possible for a standard system?
There is a point of view (which I don't share) that it is impossible to
implement the standard word `s"` (from the File word set) in a standard
*program*. I.e., that the following definition for `s"` is not standard

The double negation makes it hard to understand.

Yes. Sometimes it's hard to express yourself clearly right away ))

Post by a***@spenarnc.xs4all.nl
You are of the opinion that it is possible to implement s" in a standard program.
You mean that the following code is standard compliant.

Yes. And my opinion is even stronger: this definition for `s"` both
standard compliant and implements `s"` specified in the section
11.6.1.2165 of Forth-2012.

I also wanted to say that there is an opinion that this definition does
not implement `s"` specified in 11.6.1.2165. An interesting question for
those who share this opinion: how can 11.6.1.2165 be changed (if at all)
to allow this implementation? Maybe I have asked this before, but I
can't find any answers at the moment.

Post by a***@spenarnc.xs4all.nl
You throw in the heap (ALLOCATE), that requires a powerful system, okay.
If you require SLITERAL ALLOCATE TUCK (that are not present e.g. in the
ciforth kernel) what is the probability that S" still has to be defined?

This does not matter. For example, if a program needs more than two
buffers for `s"` interpretation, it might test and redefine `s"`.

Post by a***@spenarnc.xs4all.nl
(In ciforth it is already defined).

Post by Ruvim

Post by a***@spenarnc.xs4all.nl

Post by Ruvim
: s" ( "ccc" -- sd | )
[char] " parse
; immediate

/*****************************************************************************/
/* This is not true. */
/*****************************************************************************/
I have demonstrated that it is possible to make numbers state smart
(the excursion to S" serves only to muddy the waters) where
the definition of number or S" doesn't contain a reference to STATE.

It seems, you have misunderstood what I said. I have said "in a standard
*program*", not "in a standard system".

I misunderstood it. In fact the longer I look, the less I understand.
Of course a number of standard words cannot be portably implemented.
That is a remark I have made myself.

Agreed.

Post by a***@spenarnc.xs4all.nl
In this case you say that in
a Forth where an arbitrary set of difficult words are implemented
it is possible to define S" portably in terms of standard words.
So true.

Yes.

Post by a***@spenarnc.xs4all.nl
If I add the condition that STATE is only used in INTERPRET,
that is cheating, and largely irrelevant.

Post by Ruvim
This is important for standard libraries that may need to define or
redefine some standard words. Here by standard library I mean a standard
program that, when loaded, does not make the standard system non-standard.

Agreed. However standard libraries are not useful in the context of
gforth where every imaginable word in the standard is present,
unless for the purpose of exactly defining meaning.

I mean, a possibility to define and redefine standard words is important
for standard programs for which a Standard System must exist after the
program is loaded.

Post by a***@spenarnc.xs4all.nl

Post by Ruvim
| - whether a Standard System exists after the program is loaded.

I remember Algol68 went that route. Most features are explained
in Algol68 itself, with the remark that the implementer should
think of more clever ways to do it. Is this similar?

Maybe, but not quite :)

Post by a***@spenarnc.xs4all.nl

Post by Ruvim

Post by a***@spenarnc.xs4all.nl

Post by Ruvim
Even in some classic single-xt systems, one xt can be associated with
many nt. (of course, what is now "nt" was known as "NFA").

I cringe on this formulation.

This is what the standard says. Namely, the section "3.1.3.5 Execution
tokens" says: "Different definitions may have the same execution token
if the definitions are equivalent".
1 constant a
1 constant b
' a ' b = .
It is possible for a standard system to print "-1" when interpreting
this program.

I have a hard time with this. I can't argue with the standard however.
"I cringe that this is in the standard."

Why? This only adds some freedom to systems and imposes some light
restrictions on programs (when xt-s of user-defined words are used as
identifiers for some other things).


--
Ruvim

[Anton Ertl]

Post by Ruvim
I also wanted to say that there is an opinion that this definition does
not implement `s"` specified in 11.6.1.2165. An interesting question for
those who share this opinion: how can 11.6.1.2165 be changed (if at all)
to allow this implementation?

The implementation is not in your posting, but I guess you mean a
STATE-smart implementation. One way to allow a STATE-smart
implementation of S" would be to state something like the following in
the "Interpretation:" section of the glossary entry of 11.6.1.2165:

An ambiguous condition exists if the interpretation semantics of S" is
performed in other than interpration state.

Likewise, add the following to the "Compilation:" section:

An ambiguous condition exists if the compilation semantics of S" is
performed in other than compilation state.

- anton

[Ruvim]

Post by Anton Ertl

Post by Ruvim
I also wanted to say that there is an opinion that this definition does
not implement `s"` specified in 11.6.1.2165. An interesting question for
those who share this opinion: how can 11.6.1.2165 be changed (if at all)
to allow this implementation?

The implementation is not in your posting, but I guess you mean a
STATE-smart implementation. One way to allow a STATE-smart
implementation of S" would be to state something like the following in
An ambiguous condition exists if the interpretation semantics of S" is
performed in other than interpration state.
An ambiguous condition exists if the compilation semantics of S" is
performed in other than compilation state.

So, according to this approach, in the specification for every
unordinary word that is allowed to be implemented as a single-xt or as a
dual-xt word, you have to mention these ambiguous conditions.

This would be a poor language for specification such words, I think.

It looks like in this approach, you actually partially specify a
behavior for xt1 and partially specify a behavior for xt2, and you also
specify in which STATE xt1 shall be executed, and in which STATE xt2
shall be executed. One problem in this approach is that you have to
repeat the latter for every such word. And another problem is that you
still don't specify how to obtain xt1 and xt2.


A better way is to only specify what behavior shall be exhibit when the
Forth text interpreter encounters the word in interpretation state (the
(observable) interpretation semantics), and what behavior shall be
exhibit when the Forth text interpreter encounters the word in
compilation state (the (observable) compilation semantics). And in a
*common* part specify once how to perform this or that behavior.




For example, we can say:

Performing the execution semantics of a word in interpretation state
shall exhibit the (observable) interpretation semantics of the word.

An ambiguous condition exists if execution semantics for a word are not
defined by the standard and the system-dependent execution semantics of
the word are performed in compilation state.

An ambiguous condition exists if interpretation semantics for a word are
not defined by the standard and the system-dependent execution semantics
of the word are performed.

Note. The execution semantics of a word are identified by an execution
token that can be obtained using `find` in interpretation state,
`search-wordlist`, `name>interpret`, `'`, `[']`.

Note. At the moment, if a Forth system provides some standard word and
does not provide an execution token of this word, then the system cannot
provide the word `forth-wordlist` (due to 16.6.1.1595).



Concerning performing (observable) compilation semantics — this should
be specified in `find`, and `name>compile`. In `search-wordlist` we
should better specify the meaning of the top output value.


--
Ruvim

[a***@spenarnc.xs4all.nl]

Post by mhx

Post by Ruvim
Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.

First define exactly the [new things] that can be done with an xt or an
nt.
What some of my customers tried is, by using standard words, associate
generated code sequences with an xt (nearly impossible), or infer an nt
from an xt (which is not 1-to-n [n>=3], and asymmetrical).
A limited/qualified guarantee for the nt-xt relationship can be useful.
Example: DEFER aa ' DROP IS aa allows to recover the nt "DROP" from

My take is that per definition xt is a behaviour, and no name associated.
An empty nt (but this is a misnomer!) has no name, no behaviour, no data,
an empty link field, and as far as other fields are present, they are empty
too.
In this situation one can fill in the behaviour into an nt, assign a
name to it, or link it into a wordlist.
If you have an xt, the only thing to do is run it, i.e. execute.
There is no guarantee that there is name associated with it, that
it is part of wordlist, and the data is only accessible if it
is associated with a CREATEd word, which imply that it has a name.

A word aliased in another wordlist can have the same behaviour
exact same xt, not to speak from compile and interpret xt's.

No wonder people get confused.

Post by mhx
-marcel

[Anthony Howe]

Do you think that the Forth standard should recognize the classic single-xt
approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token (xt) is
associated with a name token (nt), and only one name token is associated with a
word (a named Forth definition). And words whose compilation semantics differ
form default compilation semantics are implemented as immediate words.

Given I prefer single-xt (currently), what I don't get is how for a dual-xt
system you define a single word with two actions for interpret and compile. I
don't see a word to distinguish between the two, except maybe IMMEDIATE.

: s" ( "ccc" -- sd | )
[char] " parse
; immediate

Do you define the same word twice, once for compile (immediate) and again for
interpret (order of definitions should not be important). Example:

: s" ( "ccc" -- sd | ) postpone sliteral ; immediate
: s" ( "ccc" -- sd | ) dup >r allocate throw tuck r@ move r> ;

[Anton Ertl]

Post by Anthony Howe

Do you think that the Forth standard should recognize the classic single-xt
approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token (xt) is
associated with a name token (nt), and only one name token is associated with a
word (a named Forth definition). And words whose compilation semantics differ
form default compilation semantics are implemented as immediate words.

Given I prefer single-xt (currently), what I don't get is how for a dual-xt
system you define a single word with two actions for interpret and compile.

If you want the interpretation and compilation semantics,
NAME>INTERPRET gives you the interpretation semantics of the word, and
NAME>COMPILE gives you the compilation semantics.

Post by Anthony Howe
I
don't see a word to distinguish between the two, except maybe IMMEDIATE.

There is no standardized way to define words with arbitrary
combinations of interpretation and compilation semantics. I don't
consider this to be a problem. We would need such words only for
defining words like S", and we don't need additional words of this
kind.

If you want to see where going for full support for defining arbitrary
combinations leads, read our EuroForth 2019 paper [paysan&ertl19].

@InProceedings{paysan&ertl19,
author = {Bernd Paysan and M. Anton Ertl},
title = {The new {Gforth} Header},
crossref = {euroforth19},
pages = {5--20},
url = {http://www.euroforth.org/ef19/papers/paysan.pdf},
url-slides = {http://www.euroforth.org/ef19/papers/paysan-slides.pdf},
video = {https://wiki.forth-ev.de/doku.php/events:ef2019:header},
OPTnote = {refereed},
abstract = {The new Gforth header is designed to directly
implement the requirements of Forth-94 and
Forth-2012. Every header is an object with a fixed
set of fields (code, parameter, count, name, link)
and methods (\texttt{execute}, \texttt{compile,},
\texttt{(to)}, \texttt{defer@}, \texttt{does},
\texttt{name>interpret}, \texttt{name>compile},
\texttt{name>string}, \texttt{name>link}). The
implementation of each method can be changed
per-word (prototype-based object-oriented
programming). We demonstrate how to use these
features to implement optimization of constants,
\texttt{fvalue}, \texttt{defer}, \texttt{immediate},
\texttt{to} and other dual-semantics words, and
\texttt{synonym}.}
}

@Proceedings{euroforth19,
title = {35th EuroForth Conference},
booktitle = {35th EuroForth Conference},
year = {2019},
key = {EuroForth'19},
url = {http://www.euroforth.org/ef19/papers/proceedings.pdf}
}

Post by Anthony Howe

: s" ( "ccc" -- sd | )
[char] " parse
; immediate

This definition does not implement the standard word CORE S" or FILE
S" (maybe if he redefined NAME>INTERPRET and NAME>COMPILE, and
consequently POSTPONE, and ', but he doesn't do that).

- anton

[Anthony Howe]

Post by Anton Ertl
There is no standardized way to define words with arbitrary
combinations of interpretation and compilation semantics. I don't
consider this to be a problem. We would need such words only for
defining words like S", and we don't need additional words of this
kind.

`STATE` smart words are essentially composite words of behaviour when compiled
and when interpreted.

a/ Outside of `INTERPRET` use of `NAME>COMPILE` and `NAME>INTERPRET`, what is
the point of obtaining the `xt` of a interpreted word? Isn't `INTERPRET` pretty
implementation specific having intimate knowledge of the internals?

b/ If `STATE` smart words are problematic ( S" S\" ACTION-OF TO IS ), why not
separate them into their composite parts which you can then obtain an `xt`? (I
know there is a painful dislike of adding new words that never existed before).

c/ Allow `STATE` smart words, but claim that trying to obtain the interpreting
`xt` as non-portable behaviour (punt) and system/implementation specific. OR
the corollary...

c'/ Only allow obtaining the compile `xt` of `STATE` smart words as portable.

[Stephen Pelc]

Post by Anthony Howe

Do you think that the Forth standard should recognize the classic single-xt
approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token (xt) is
associated with a name token (nt), and only one name token is associated with a
word (a named Forth definition). And words whose compilation semantics differ
form default compilation semantics are implemented as immediate words.

Given I prefer single-xt (currently), what I don't get is how for a dual-xt
system you define a single word with two actions for interpret and compile. I
don't see a word to distinguish between the two, except maybe IMMEDIATE.

VFX Forth 64 is a single xt system (with sub-xts) . It manages to separate
compilation and interpret actions for a word cleanly. S" is defined as below:

: S" \ Comp: "ccc<quote>" -- ; Run: -- c-addr u 6.1.2165
\ *G Describe a string. Text is taken up to the next double-quote
\ ** character. The address and length of the string are returned.
[char] " parse >syspad
;
ndcs: ( -- ) discard-sinline compile (s") ", ;

NDCS: describes the non-default compilation sematics of the word. The
process of arriving at this model is described in several recent EuroForth
papers.

[Ruvim]

Post by Stephen Pelc

Post by Anthony Howe

Do you think that the Forth standard should recognize the classic single-xt
approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token (xt) is
associated with a name token (nt), and only one name token is associated with a
word (a named Forth definition). And words whose compilation semantics differ
form default compilation semantics are implemented as immediate words.

Given I prefer single-xt (currently), what I don't get is how for a dual-xt
system you define a single word with two actions for interpret and compile. I
don't see a word to distinguish between the two, except maybe IMMEDIATE.

VFX Forth 64 is a single xt system (with sub-xts) .

If VFX Forth allows to obtain sub-xts from the main xt, then FVX Forth
effectively has multiple xts associated with an nt.

Moreover, in VFX Forth, the execution semantics of `FIND` depends on
STATE (at least, for some arguments). Therefore, VFX Forth does not
follow the classic single-xt approach.

Post by Stephen Pelc
It manages to separate
: S" \ Comp: "ccc<quote>" -- ; Run: -- c-addr u 6.1.2165
\ *G Describe a string. Text is taken up to the next double-quote
\ ** character. The address and length of the string are returned.
[char] " parse >syspad
;
ndcs: ( -- ) discard-sinline compile (s") ", ;
NDCS: describes the non-default compilation sematics of the word.

This implementation is not standard compliant, because `compile,`, which
shall has stack effect ( xt -- ), consumes and produces some other stack
parameters for some xts, e.g.

' if compile, \ actual effect( xt -- x )

' then compile, \ actual effect ( x xt -- )


Or, in a standard program:

: test-compile(
state @ 0= -14 and throw
bl word find if compile, else -13 throw then
parse-name s" )" compare abort" ')' expected"
; immediate

: foo test-compile( if ) ;

\ Err# -22 ERR: Control structure mismatch.


--
Ruvim

[mhx]

On Wed, 18 Sep 2024 6:10:29 +0000, Ruvim wrote:
[..]

Post by Ruvim
This implementation is not standard compliant, because `compile,`, which
shall has stack effect ( xt -- ), consumes and produces some other stack
parameters for some xts, e.g.

[..]

Post by Ruvim
: test-compile(
bl word find if compile, else -13 throw then
parse-name s" )" compare abort" ')' expected"
; immediate
: foo test-compile( if ) ;
\ Err# -22 ERR: Control structure mismatch.

FORTH> see foo
Flags: ANSI
$01340E40 : foo
$01340E4A jmp IF+10 ( $012B829A ) offset NEAR
$01340E4F ;

I'm curious what this tells you.

-marcel

[Ruvim]

Post by mhx
[..]

Post by Ruvim
This implementation is not standard compliant, because `compile,`, which
shall has stack effect ( xt -- ), consumes and produces some other stack
parameters for some xts, e.g.

[..]

Post by Ruvim
   : test-compile(
     bl word find if compile, else -13 throw then
     parse-name s" )" compare abort" ')' expected"
   ; immediate
   : foo test-compile( if ) ;
   \ Err# -22 ERR: Control structure mismatch.

FORTH> see foo
Flags: ANSI
$01340E40  : foo
$01340E4A  jmp           IF+10 ( $012B829A ) offset NEAR
$01340E4F  ;
I'm curious what this tells you.

This tells me that in iForth the word `compile,` behaves as expected in
this test :)


--
Ruvim

[Ruvim]

Post by Anthony Howe

Post by Ruvim
Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.

Given I prefer single-xt (currently),

Me too.

Actually, most Forth systems are classic single-xt systems. And most
educational materials on how to implement Forth explain the classic
single-xt approach.

One example: https://github.com/uho/minimal
see: https://github.com/uho/minimal/blob/master/compiling-words.fs

Post by Anthony Howe
what I don't get is how for a
dual-xt system you define a single word with two actions for interpret
and compile. I don't see a word to distinguish between the two, except
maybe IMMEDIATE.

Post by Ruvim
  : s" ( "ccc" -- sd | )
    [char] " parse
  ; immediate

Do you define the same word twice, once for compile (immediate) and
again for interpret (order of definitions should not be important).
: s" ( "ccc" -- sd | ) postpone sliteral ; immediate

Namely this cannot be standard compliant. But yes, something similar.
There are different ways in different systems.

For example, it might look like this:

: s" ( "ccc<quot>" -- ) postpone sliteral ; immediate

interpret: s" ( "ccc<quot>" -- sd )
dup >r allocate throw tuck r@ move r>
;

or

interp: s" ( "ccc<quot>" -- sd )
dup >r allocate throw tuck r@ move r>
;interp


Where (in a classic single-xt system):

: interpret: ( "<spaces>name" -- colon-sys )
parse-name get-current search-wordlist
dup 0 = abort" (not found; comp semantics must be defined first)"
-1 = abort" (the found word is not immediate)"
( xt.compilation ) build-interpretation-slot ( a-addr )

Post by Anthony Howe
r depth >r :noname ( xt colon-sys ) r> 1- roll r> !

;

: obtain-interpretation ( xt1 -- xt1 | xt2 )
dup lookup-interpretation-slot dup if nip @ exit then drop
;

: find ( c-addr -- c-addr 0 | xt 1 | xt -1 )

Post by Anthony Howe
r obtain-interpretation r>

then then then
;

: name>interpret ( nt -- xt|0 )
name>interpret obtain-interpretation
;


And this makes a classic single-xt system a dual-xt system.

But we still have to execute the result of "name>interpret" *only* in
interpretation state if we want to perform the interpretation semantics
of the word. Because we don't know whether the execution semantics
identified by the returned xt depend on STATE. And if they depend, we
must execute them in interpretation state to perform the interpretation
semantics.

Therefore, having a second xt gives us little benefit.

NB: when we want to perform the interpretation semantics for a word, we
want to perform *exactly* the behavior that the system exhibits when the
name of that word is encountered by the Forth text interpreter in
interpretation state. There are no examples yet where we need anything
else.


--
Ruvim

[Ruvim]

[...]

Post by Ruvim

what I don't get is how for a dual-xt system you define a single word
with two actions for interpret and compile. I don't see a word to
distinguish between the two, except maybe IMMEDIATE.

[...]

Post by Ruvim

Do you define the same word twice, once for compile (immediate) and
again for interpret (order of definitions should not be important).
: s" ( "ccc" -- sd | ) postpone sliteral ; immediate

Namely this cannot be standard compliant. But yes, something similar.
There are different ways in different systems.
  : s" ( "ccc<quot>" -- ) postpone sliteral ; immediate
  interpret: s" ( "ccc<quot>" -- sd )
  ;
or
  interp: s" ( "ccc<quot>" -- sd )
  ;interp

Typo: parsing is missed.

Correction:

: s" ( "ccc<quot>" -- ) '"' parse postpone sliteral ; immediate

interpret: s" ( "ccc" -- sd )
'"' parse
dup >r allocate throw tuck r@ move r>
;

Post by Ruvim
  : interpret: ( "<spaces>name" -- colon-sys )
    parse-name get-current search-wordlist
    dup 0 = abort" (not found; comp semantics must be defined first)"
       -1 = abort" (the found word is not immediate)"
    ( xt.compilation ) build-interpretation-slot ( a-addr )
    >r depth >r :noname ( xt colon-sys ) r> 1- roll r> !
  ;
  : obtain-interpretation ( xt1 -- xt1 | xt2 )
  ;
  : find ( c-addr -- c-addr 0 | xt 1 | xt -1 )
      >r obtain-interpretation r>
    then then then
  ;
  : name>interpret ( nt -- xt|0 )
    name>interpret obtain-interpretation
  ;
And this makes a classic single-xt system a dual-xt system.
But we still have to execute the result of "name>interpret" *only* in
interpretation state if we want to perform the interpretation semantics
of the word.  Because we don't know whether the execution semantics
identified by the returned xt depend on STATE.  And if they depend, we
must execute them in interpretation state to perform the interpretation
semantics.
Therefore, having a second xt gives us little benefit.
NB: when we want to perform the interpretation semantics for a word, we
want to perform *exactly* the behavior that the system exhibits when the
name of that word is encountered by the Forth text interpreter in
interpretation state.  There are no examples yet where we need anything
else.
--
Ruvim

[Hans Bezemer]

Post by Ruvim
Actually, most Forth systems are classic single-xt systems. And most
educational materials on how to implement Forth explain the classic
single-xt approach.

Interesting enough - considering this "dual xt" idea, 4tH has *ALWAYS*
been "dual xt". All compilation behavior is in the compiler and all
execution behavior is in the interpreter. Note 4tH *only* contains
primitives. The Forth layer is what you build with these primitives,
since both the compilation behavior and execution behavior is coded in C.

Hans Bezemer

[a***@spenarnc.xs4all.nl]

Post by Hans Bezemer

Post by Ruvim
Actually, most Forth systems are classic single-xt systems. And most
educational materials on how to implement Forth explain the classic
single-xt approach.

Interesting enough - considering this "dual xt" idea, 4tH has *ALWAYS*
been "dual xt". All compilation behavior is in the compiler and all
execution behavior is in the interpreter. Note 4tH *only* contains
primitives. The Forth layer is what you build with these primitives,
since both the compilation behavior and execution behavior is coded in C.

And the opposite approach. Always have default compilation semantics,
i.e. add the behaviour of an interpreted word to a compiled word.
Do not allow STATE dependant behaviour except for denotations:
single words that leave a constant or several constant(s) on
the stack, but this must be the same value for interpretation and interpretation. 1)
They are compiled as literals in compilation mode.
Do not allow to postpone denotations (use literal for that),
do not allow any other state smart words.

Forth doesn't become less powerful, only less interesting for
language lawyers.
If the compilation stack is separate, inspection of STATE
can be restricted to INTERPRET , without even a need to
be inspected by number, aka denotations.
INTERPRET could simply inspect if the stack has changed.
In compile mode, it compiles literals, instead of leaving
them on the stack.

(Chuck Moore would/should like this.)

The only reason to have dual xt if you want to do
optimisation in the compilation xt.


1) Note that a :NONAME construction is an denotation, leaving a
constant xt.

Post by Hans Bezemer
Hans Bezemer

Groetjes Albert

[Hans Bezemer]

Post by a***@spenarnc.xs4all.nl

Post by Hans Bezemer

Post by Ruvim
Actually, most Forth systems are classic single-xt systems. And most
educational materials on how to implement Forth explain the classic
single-xt approach.

Interesting enough - considering this "dual xt" idea, 4tH has *ALWAYS*
been "dual xt". All compilation behavior is in the compiler and all
execution behavior is in the interpreter. Note 4tH *only* contains
primitives. The Forth layer is what you build with these primitives,
since both the compilation behavior and execution behavior is coded in C.

And the opposite approach. Always have default compilation semantics,
i.e. add the behaviour of an interpreted word to a compiled word.

That is handled by two tables in the 4tH compiler: one to add primitive
words *WITH* an argument (like built-in constants) and one for words
*WITHOUT* (like DUP, ROT, PARSE, etc).

Words which do not translate to simple "instruction(argument)" pairs are
in the third table (IF, VALUE, :, ;, etc.) And then there's the symbol
table which again, contains simple "instruction(argument)" pairs.

Post by a***@spenarnc.xs4all.nl
If the compilation stack is separate, inspection of STATE
can be restricted to INTERPRET , without even a need to
be inspected by number, aka denotations.
INTERPRET could simply inspect if the stack has changed.
In compile mode, it compiles literals, instead of leaving
them on the stack.

In certain situations the growing compilant is used as a stack in 4tH
i.e. the last word compiled *MUST* be a LITERAL for it to work.
Fortunately, the 4tH optimizer does a great job when constant folding.

Hans Bezemer

[Anton Ertl]

Post by Ruvim
Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?

I think that that's certainly intended at some point by the
standardization committee, and I would support reasonable changes to
the standard to make such systems standard-conforming. But I think
it's up to the people who have implemented such a system (in
particular, Forth, Inc.) to propose something reasonable in this
direction. They have not done so (and there has been ample
opportunity), so they seem to be happy with the current state of
affairs: SwiftForth does not comply with the standard for S" and a
number of other words, but apparently nobody has complained, so they
won't fix these words nor propose changing the standard.

An alternative (and probably less work than changing the standard) is
to fix SwiftForth (e.g., by special-casing the dual-sematics words in
NAME>INTERPRET and NAME>COMPILE), but it's even less work is to let
sleeping dogs lie.

- anton

[Ruvim]

Post by Ruvim
Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.

Or, a different question (because you could have another point of view):

Do you think that the Forth standard should recognize the classic
single-xt approach as *impossible* for implementing a standard Forth
system? And consequently, it should be *impossible* for a standard
*program* to implement the standard `s"` word (from the File-Access word
set) as an immediate word, for example, as:

: s" ( "ccc" -- sd | )
[char] " parse
state @ if postpone sliteral exit then
dup >r allocate throw tuck r@ move r>
; immediate

(I.e., you think that currently the above definition implements the
standard `s"` word, but it should not in a future version of the standard).


--
Ruvim

[PMF]

Post by Ruvim
Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.
--
Ruvim

In my opinion the Forth standard should not care about implementation
details like how a header is organized ( single, dual xt or some other
way).

My system lxf/ntf was probably one of the first to introduce dual xts.
I saw this as a clean way to implement specific compilation behavior
for the native code generation. I started with the cmforth idea to have
separate compilation and interpretation wordlists. This worked well
until I also needed several different wordlists for other purposes.
From that came the idea of two xts.

The lxf64 I am working on now has instead a single xt. This will change
in the future when the native code generator is finished. The header
will then probable have 3 xts! at least logically.

- one to the bytecode
- one to interpreting code
- one for the compile-time code

The system compiles to bytecode ( a token threaded system ).
It runs very well on just the bytecode, only 5-10 times slower then lxf.
The bytecode is needed to give a well working inlining possibility.
The compile-time action will then be either to inline the bytecode or
compile a call to already compiled native code.
The interpreting code will be generated when the bytecode is compiled
and sent to the native code-generator that produces assembler source
that is feed into an external assembler.

The header will then store a pointer to the compiled interpreting code
the byte code will follow directly after the header and the compile
time action can be determined from flags in the header.

Looking back at the standard, in my opinion it was a mistake to
standardize the nt! It would have been better to have
FIND-INTERPRET instead of FIND-NAME NAME>INTERPRET and
FIND-COMPILE instead of FIND-NAME NAME>COMPILE.

That would have given more freedom to organize the internal header
structure.

BR
Peter Fälth

[Anton Ertl]

Post by PMF
In my opinion the Forth standard should not care about implementation
details like how a header is organized ( single, dual xt or some other
way).

It does not. SwiftForth could implement a standard-conforming FILE S"
without changing the header structure.

Post by PMF
Looking back at the standard, in my opinion it was a mistake to
standardize the nt! It would have been better to have
FIND-INTERPRET instead of FIND-NAME NAME>INTERPRET and
FIND-COMPILE instead of FIND-NAME NAME>COMPILE.

And FIND-INTERPRET-IN and FIND-COMPILE-IN. What about
TRAVERSE-WORDLIST? Would you then have TRAVERSE-WORDLIST-INTERPRET
and TRAVERSE-WORDLIST-COMPILE? If so, how should MWORDS
<http://theforth.net/package/mwords> behave?

Post by PMF
That would have given more freedom to organize the internal header
structure.

OTOH, the nt turns named words into a first-class concept that has its
own handle, enabling words like TRAVERSE-WORDLIST and allowing
programmers to write words like MWORDS.

Very few system implementors use several headers per word (making the
nt hard to implement), and none of these systems is widely used (have
they been published at all)?

And standardizing the nt has not taken away this freedom. The nt and
all the words that deal with it are in TOOLS EXT and therefore optional.

So you are not asking for freedom to organize the internal header
structure in a standard system, but you are begrudging the programmers
the freedom to write programs like MWORDS as a standard program
requiring several words from the Programming-Tools Extensions word
set.

- anton

[Ruvim]

On 2024-09-22 01:28, PMF wrote:
[...]

Post by PMF
Looking back at the standard, in my opinion it was a mistake to
standardize the nt!  It would have been better to have
FIND-INTERPRET  instead of FIND-NAME NAME>INTERPRET  and
FIND-COMPILE  instead of FIND-NAME NAME>COMPILE.
That would have given more freedom to organize the internal header
structure.

We already have a kind of FIND-INTERPRET and FIND-COMPILE from Forth-94.
It is the FIND word, which depends on STATE.


--
Ruvim

[Gerry Jackson]

Post by Anton Ertl

Post by mhx
[..]

Post by Ruvim
1 constant a
1 constant b
' a ' b = .

...

Post by mhx
Why? 'a' and 'b' are user defined words, '=' is a standard word,
and 'true' is the expected outcome.

Are you sure?
[~:152648] iforth
FORTH> 1 constant a ok
FORTH> 1 constant b ok
FORTH> ' a ' b = . 0 ok
I actually know of no system that outputs -1.
- anton

I know it's different but:

1 constant a
synonym b a
' a ' b = . \ displayed -1 in 5 out of 6 Forths I just tried, including
GForth.

Comparing xt's is unsafe

[Ruvim]

Post by Ruvim

Post by Anton Ertl

Post by mhx
[..]

   1 constant a
   1 constant b
   ' a ' b = .

...

Post by mhx
Why? 'a' and 'b' are user defined words, '=' is a standard word,
and 'true' is the expected outcome.

Are you sure?
[~:152648] iforth
FORTH> 1 constant a  ok
FORTH> 1 constant b  ok
FORTH> ' a ' b = . 0  ok
I actually know of no system that outputs -1.
- anton

1 constant a
synonym b a
' a ' b = . \ displayed -1 in 5 out of 6 Forths I just tried, including
GForth.
Comparing xt's is unsafe

The same xt means the same execution semantics and nothing more.

But the same execution semantics can be identified by different xt-s.
Thus, from two different xt-s one cannot say whether they identify
different execution semantics or the same execution semantics.



--
Ruvim

[a***@spenarnc.xs4all.nl]

Post by Ruvim

Post by Anton Ertl

Post by mhx
[..]

Post by Ruvim
1 constant a
1 constant b
' a ' b = .

...

Post by mhx
Why? 'a' and 'b' are user defined words, '=' is a standard word,
and 'true' is the expected outcome.

Are you sure?
[~:152648] iforth
FORTH> 1 constant a ok
FORTH> 1 constant b ok
FORTH> ' a ' b = . 0 ok
I actually know of no system that outputs -1.
- anton

1 constant a
synonym b a
' a ' b = . \ displayed -1 in 5 out of 6 Forths I just tried, including
GForth.
Comparing xt's is unsafe

Look at this. An alias in ciforth is a word that has a different
name and behaves exactly the same.

1 CONSTANT B
OK
'B ALIAS A
OK
'B 'A = .
0 OK
'B >DFA 'A >DFA = \ Where the constants are stored.
OK
.
0 OK \ False
B A = .
-1 \ True
VARIABLE B
OK
'B ALIAS A
OK
12 B !
OK
A ?
12 OK \ !!!!!

P.S. 'B is the nt (a prefer dea) of B.
A is the same variable than B, only with a different name.

Post by Ruvim
--
Gerry