Path: ...!3.eu.feeder.erje.net!feeder.erje.net!news.in-chemnitz.de!news.swapon.de!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: Mon, 23 Sep 2024 01:15:48 +0400
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <vcq1e5$25spg$7@dont-email.me>
References: <vcbn5e$3etuk$1@dont-email.me>
 <1a3ebf77c1ed8926d455a268e1309fe0@www.novabbs.com>
 <vcbuog$3etuk$3@dont-email.me> <nnd$0f2e6033$478228ed@d9a7750878a12d98>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 22 Sep 2024 23:15:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="549a3fe37f3214051d88622e687b5f68";
	logging-data="2290480"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX188vkAaVpH7ANiyDbTyvedn"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:4tmJujh58XpiVlirfy6IZ4sv9lA=
Content-Language: en-US
In-Reply-To: <nnd$0f2e6033$478228ed@d9a7750878a12d98>
Bytes: 4231

On 2024-09-22 13:53, albert@spenarnc.xs4all.nl wrote:
> 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),
>>
>>> 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.

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