Re: single-xt approach in the standard

Liste des GroupesRevenir à cl forth 
Sujet : Re: single-xt approach in the standard
De : albert (at) *nospam* spenarnc.xs4all.nl
Groupes : comp.lang.forth
Date : 22. Sep 2024, 10:53:02
Autres entêtes
Organisation : KPN B.V.
Message-ID : <nnd$0f2e6033$478228ed@d9a7750878a12d98>
References : 1 2 3
User-Agent : trn 4.0-test77 (Sep 1, 2010)
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.
>
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 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.]

>
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.

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.

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

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.
--
Ruvim
>

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

Date Sujet#  Auteur
17 Sep 24 * single-xt approach in the standard78Ruvim
17 Sep 24 +* Re: single-xt approach in the standard15minforth
17 Sep 24 i`* Re: single-xt approach in the standard14Ruvim
17 Sep 24 i `* Re: single-xt approach in the standard13Anthony Howe
18 Sep 24 i  +* Re: single-xt approach in the standard7dxf
18 Sep 24 i  i`* Standardization process (was: single-xt approach in the standard)6Ruvim
18 Sep 24 i  i `* Re: Standardization process5dxf
18 Sep 24 i  i  +* Re: Standardization process3Ruvim
18 Sep 24 i  i  i`* Re: Standardization process2dxf
18 Sep 24 i  i  i `- Re: Standardization process1Ruvim
18 Sep 24 i  i  `- Re: Standardization process1Ruvim
18 Sep 24 i  `* Re: single-xt approach in the standard5Ruvim
18 Sep 24 i   `* Re: single-xt approach in the standard4Gerry Jackson
19 Sep 24 i    +- Re: single-xt approach in the standard1albert
19 Sep 24 i    `* Standard testsuite (was: single-xt approach in the standard)2Ruvim
19 Sep 24 i     `- Re: Standard testsuite (was: single-xt approach in the standard)1albert
17 Sep 24 +* Re: single-xt approach in the standard46mhx
17 Sep 24 i+* Re: single-xt approach in the standard44Ruvim
17 Sep 24 ii+* Re: single-xt approach in the standard2minforth
17 Sep 24 iii`- Re: single-xt approach in the standard1Ruvim
21 Sep 24 ii+* Re: single-xt approach in the standard28dxf
21 Sep 24 iii`* Re: single-xt approach in the standard27Ruvim
22 Sep 24 iii `* Re: single-xt approach in the standard26dxf
22 Sep 24 iii  +* Re: single-xt approach in the standard6Anton Ertl
22 Sep 24 iii  i+- Re: single-xt approach in the standard1albert
23 Sep 24 iii  i`* Re: single-xt approach in the standard4dxf
23 Sep 24 iii  i `* Re: single-xt approach in the standard3Anthony Howe
24 Sep 24 iii  i  +- Re: single-xt approach in the standard1dxf
25 Sep 24 iii  i  `- Re: single-xt approach in the standard1dxf
22 Sep 24 iii  `* Re: single-xt approach in the standard19Ruvim
22 Sep 24 iii   +* Re: single-xt approach in the standard5Anton Ertl
22 Sep 24 iii   i`* Semantics as observable behavior (was: single-xt approach in the standard)4Ruvim
22 Sep 24 iii   i `* Re: Semantics as observable behavior (was: single-xt approach in the standard)3Anton Ertl
22 Sep 24 iii   i  `* Re: Semantics as observable behavior2Ruvim
23 Sep 24 iii   i   `- Re: Semantics as observable behavior1Ruvim
22 Sep 24 iii   +* Re: single-xt approach in the standard4albert
22 Sep 24 iii   i`* Re: single-xt approach in the standard3Ruvim
23 Sep 24 iii   i `* Re: single-xt approach in the standard2albert
23 Sep 24 iii   i  `- Re: single-xt approach in the standard1minforth
23 Sep 24 iii   `* Re: single-xt approach in the standard9dxf
23 Sep 24 iii    `* Standard compliance for systems (was: single-xt approach in the standard)8Ruvim
22 Nov 24 iii     `* Re: Standard compliance for systems7dxf
22 Nov 24 iii      `* Re: Standard compliance for systems6minforth
22 Nov 24 iii       +* Re: Standard compliance for systems3mhx
22 Nov 24 iii       i`* Re: Standard compliance for systems2minforth
22 Nov 24 iii       i `- Re: Standard compliance for systems1mhx
23 Nov 24 iii       `* Re: Standard compliance for systems2dxf
24 Nov 24 iii        `- Re: Standard compliance for systems1dxf
21 Sep 24 ii+* Re: single-xt approach in the standard4Stephen Pelc
21 Sep 24 iii`* Re: single-xt approach in the standard3Ruvim
22 Sep 24 iii `* Re: single-xt approach in the standard2Stephen Pelc
22 Sep 24 iii  `- Re: single-xt approach in the standard1Anton Ertl
22 Sep 24 ii`* Re: single-xt approach in the standard9albert
22 Sep 24 ii `* Re: single-xt approach in the standard8Ruvim
23 Sep 24 ii  `* Re: single-xt approach in the standard7albert
23 Sep 24 ii   +* Re: single-xt approach in the standard3mhx
23 Sep 24 ii   i`* Re: single-xt approach in the standard2Anton Ertl
23 Sep 24 ii   i `- Re: single-xt approach in the standard1mhx
23 Sep 24 ii   `* Re: single-xt approach in the standard3Ruvim
23 Sep 24 ii    `* Re: single-xt approach in the standard2Anton Ertl
25 Sep 24 ii     `- Re: single-xt approach in the standard1Ruvim
17 Sep 24 i`- Re: single-xt approach in the standard1albert
17 Sep 24 +* Re: single-xt approach in the standard11Anthony Howe
17 Sep 24 i+* Re: single-xt approach in the standard2Anton Ertl
24 Sep 24 ii`- Re: single-xt approach in the standard1Anthony Howe
18 Sep 24 i+* Re: single-xt approach in the standard4Stephen Pelc
18 Sep 24 ii`* Re: single-xt approach in the standard3Ruvim
18 Sep 24 ii `* Re: single-xt approach in the standard2mhx
19 Sep 24 ii  `- Re: single-xt approach in the standard1Ruvim
18 Sep 24 i`* Re: single-xt approach in the standard4Ruvim
18 Sep 24 i +- Re: single-xt approach in the standard1Ruvim
18 Sep 24 i `* Re: single-xt approach in the standard2Hans Bezemer
19 Sep 24 i  `- Re: single-xt approach in the standard1albert
17 Sep 24 +- Re: single-xt approach in the standard1Anton Ertl
18 Sep 24 +- Re: single-xt approach in the standard1Ruvim
21 Sep 24 `* Re: single-xt approach in the standard3PMF
22 Sep 24  +- Re: single-xt approach in the standard1Anton Ertl
22 Sep 24  `- Re: single-xt approach in the standard1Ruvim

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal