Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!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 12:15:47 +0400
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <vce27k$3unj9$3@dont-email.me>
References: <vcbn5e$3etuk$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 18 Sep 2024 10:15:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d2d49625ab619eb4a06b4d5e9f2582f6";
	logging-data="4152937"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+y7Up3PVkZEZUT12F7jxqW"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:1L5/4QeL70EJEXkdG1LmdcyOr7o=
Content-Language: en-US
In-Reply-To: <vcbn5e$3etuk$1@dont-email.me>
Bytes: 2270

On 2024-09-17 14: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.


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