Re: single-xt approach in the standard

Liste des GroupesRevenir à cl forth 
Sujet : Re: single-xt approach in the standard
De : ruvim.pinka (at) *nospam* gmail.com (Ruvim)
Groupes : comp.lang.forth
Date : 18. Sep 2024, 07:10:29
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vcdqsm$3unj9$1@dont-email.me>
References : 1 2 3
User-Agent : Mozilla Thunderbird
On 2024-09-18 03:04, Stephen Pelc wrote:
On 17 Sep 2024 at 21:12:08 CEST, "Anthony Howe" <achowe@snert.com> wrote:
 
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.
 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.

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

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