Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ruvim <ruvim.pinka@gmail.com>
Newsgroups: comp.lang.forth
Subject: Re: single-xt approach in the standard
Date: Wed, 18 Sep 2024 16:41:05 +0400
Organization: A noiseless patient Spider
Lines: 96
Message-ID: <vcehp2$2dap$1@dont-email.me>
References: <vcbn5e$3etuk$1@dont-email.me> <vccka8$3l9rv$2@dont-email.me>
 <vceac8$3unj9$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 18 Sep 2024 14:41:06 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d2d49625ab619eb4a06b4d5e9f2582f6";
	logging-data="79193"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+5tJfthvIMPz+kZMqSolct"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:PTc4Y/rVX/Zu2C44UO0mhHENO+k=
In-Reply-To: <vceac8$3unj9$5@dont-email.me>
Content-Language: en-US
Bytes: 4031

On 2024-09-18 14:34, Ruvim wrote:
> On 2024-09-17 23:12, Anthony Howe wrote:
[...]
>> 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.
>>
[...]
>> 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> ;
> 
> 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


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




> 
> 
> 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 )
>      >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 )
>      find dup if dup 1 = if state @ 0= if
>        >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
>