| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 94:11:07 |
| Calls: | 290 |
| Calls today: | 1 |
| Files: | 904 |
| Messages: | 76,378 |
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.
IMO small systems are better off with Forth-94.
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).
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.
dxf <dxforth@gmail.com> writes:
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--
On 2024-09-17 16:15, mhx wrote:
On Tue, 17 Sep 2024 10:54:37 +0000, Ruvim wrote:
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.
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").
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.
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
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.
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?
On 21 Sep 2024 at 21:18:00 CEST, "Ruvim" <ruvim.pinka@gmail.com> wrote:
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.
- 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?
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 compaaniesLeaning extensibly on Open Source Forth is probably less
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.
--
Stephen Pelc, stephen@vfxforth.com
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.
RuvimGroetjes Albert
On 2024-09-22 23:34, albert@spenarnc.xs4all.nl wrote:
In article <vcpi98$25spg$1@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:
<SNIP>
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
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.
On 2024-09-22 13:53, albert@spenarnc.xs4all.nl wrote:The double negation makes it hard to understand.
In article <vcbuog$3etuk$3@dont-email.me>,[...]
Ruvim <ruvim.pinka@gmail.com> wrote:
On 2024-09-17 16:15, mhx wrote:
On Tue, 17 Sep 2024 10:54:37 +0000, Ruvim wrote:
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.
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 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.
What some of my customers tried is, by using standard words, associate >>>> generated code sequences with an xt (nearly impossible),Even in some classic single-xt systems, one xt can be associated with
or infer an nt from an xt (which is not 1-to-n [n>=3], and asymmetrical). >>>
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
In article <vcq1e5$25spg$7@dont-email.me>,[..]
Ruvim <ruvim.pinka@gmail.com> wrote:
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."
On Mon, 23 Sep 2024 8:36:10 +0000, albert@spenarnc.xs4all.nl wrote:
In article <vcq1e5$25spg$7@dont-email.me>,[..]
Ruvim <ruvim.pinka@gmail.com> wrote:
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--
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.
On 2024-09-23 12:36, albert@spenarnc.xs4all.nl wrote:
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?
On Mon, 23 Sep 2024 8:36:10 +0000, albert@spenarnc.xs4all.nl wrote:...
In article <vcq1e5$25spg$7@dont-email.me>,[..]
Ruvim <ruvim.pinka@gmail.com> wrote:
1 constant a
1 constant b
' a ' b = .
Why? 'a' and 'b' are user defined words, '=' is a standard word,
and 'true' is the expected outcome.
[~: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.
mhx@iae.nl (mhx) writes:
On Mon, 23 Sep 2024 8:36:10 +0000,albert@spenarnc.xs4all.nl wrote:...
In article<vcq1e5$25spg$7@dont-email.me>,[..]
Ruvim<ruvim.pinka@gmail.com> wrote:
1 constant a
1 constant b
' a ' b = .
Why? 'a' and 'b' are user defined words, '=' is a standard word,Are you sure?
and 'true' is the expected outcome.
[~: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
On 23/09/2024 18:02, Anton Ertl wrote:
mhx@iae.nl (mhx) writes:
On Mon, 23 Sep 2024 8:36:10 +0000,albert@spenarnc.xs4all.nl wrote:...
In article<vcq1e5$25spg$7@dont-email.me>,[..]
Ruvim<ruvim.pinka@gmail.com> wrote:
1 constant a
1 constant b
' a ' b = .
Why? 'a' and 'b' are user defined words, '=' is a standard word,Are you sure?
and 'true' is the expected outcome.
[~: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
--
Gerry
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.
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.
On 2024-09-17 17:58, minforth wrote:
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.
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.
the poorly designed specifications of ' and POSTPONE
POSTPONE is perfectly specified. What you dislike with it?
----
Ruvim
On Tue, 17 Sep 2024 10:54:37 +0000, Ruvim wrote:
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--
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.
: s" ( "ccc" -- sd | )
[char] " parse
state @ if postpone sliteral exit then
dup >r allocate throw tuck r@ move r>
; immediate
On 2024-09-17 15:20, minforth wrote:
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.
On 2024-09-17 06:54, Ruvim wrote:
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
state @ if postpone sliteral exit then
dup >r allocate throw tuck r@ move r>
; immediate
Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
On 2024-09-17 06:54, Ruvim wrote:
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.
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.[..]
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.
On 2024-09-17 22:58, Anthony Howe wrote:
On 2024-09-17 07:59, Ruvim wrote:
On 2024-09-17 15:20, minforth wrote:
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
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);
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.
--
Gerry
On 18-09-2024 12:34, Ruvim wrote:
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