Re: single-xt approach in the standard

From	Ruvim <ruvim.pinka@gmail.com>
Newsgroups	comp.lang.forth
Subject	Re: single-xt approach in the standard
Date	2024-09-23 14:16 +0400
Organization	A noiseless patient Spider
Message-ID	<vcrf6e$25spg$11@dont-email.me> (permalink)
References	<vcbn5e$3etuk$1@dont-email.me> <vcbuog$3etuk$3@dont-email.me> <nnd$0f2e6033$478228ed@d9a7750878a12d98> <vcq1e5$25spg$7@dont-email.me> <nnd$0842ed34$3aad0e10@54a771cc5f051015>

Show all headers | View raw

On 2024-09-23 12:36, albert@spenarnc.xs4all.nl wrote:
> In article <vcq1e5$25spg$7@dont-email.me>,
> Ruvim  <ruvim.pinka@gmail.com> wrote:
>> 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:
> The double negation makes it hard to understand.

Yes. Sometimes it's hard to express yourself clearly right away ))

> You are of the opinion that it is possible to implement s" in a standard program.
> You mean that the following code is standard compliant.

Yes. And my opinion is even stronger: this definition for `s"` both 
standard compliant and implements `s"` specified in the section 
11.6.1.2165 of Forth-2012.

I also wanted to say that there is an opinion that this definition does 
not implement `s"` specified in 11.6.1.2165. An interesting question for 
those who share this opinion: how can 11.6.1.2165 be changed (if at all) 
to allow this implementation?  Maybe I have asked this before, but I 
can't find any answers at the moment.







> You throw in the heap (ALLOCATE), that requires a powerful system, okay.
> If you require SLITERAL ALLOCATE TUCK (that are not present e.g. in the
> ciforth kernel) what is the probability that S" still has to be defined?

This does not matter. For example, if a program needs more than two 
buffers for `s"` interpretation, it might test and redefine `s"`.




> (In ciforth it is already defined).
>>>>
>>>>     : 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".
> 
> I misunderstood it. In fact the longer I look, the less I understand.
> Of course a number of standard words cannot be portably implemented.
> That is a remark I have made myself. 

Agreed.


> In this case you say that in
> a Forth where an arbitrary set of difficult words are implemented
> it is possible to define S" portably in terms of standard words.
> So true.

Yes.


> 
> If I add the condition that STATE is only used in INTERPRET,
> that is cheating, and largely irrelevant.
> 
>>
>> 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.
> 
> Agreed. However standard libraries are not useful in the context of
> gforth where every imaginable word in the standard is present,
> unless for the purpose of exactly defining meaning.


I mean, a possibility to define and redefine standard words is important 
for standard programs for which a Standard System must exist after the 
program is loaded.

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



> I remember Algol68 went that route. Most features are explained
> in Algol68 itself, with the remark that the implementer should
> think of more clever ways to do it. Is this similar?

Maybe, but not quite :)




>>>> 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.
> 
> I have a hard time with this. I can't argue with the standard however.
> "I cringe that this is in the standard."

Why?   This only adds some freedom to systems and imposes some light 
restrictions on programs (when xt-s of user-defined words are used as 
identifiers for some other things).


--
Ruvim

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-17 14:54 +0400
  Re: single-xt approach in the standard minforth@gmx.net (minforth) - 2024-09-17 11:20 +0000
    Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-17 15:59 +0400
      Re: single-xt approach in the standard Anthony Howe <achowe@snert.com> - 2024-09-17 14:58 -0400
        Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-18 13:39 +1000
          Standardization process (was: single-xt approach in the standard) Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 11:07 +0400
            Re: Standardization process dxf <dxforth@gmail.com> - 2024-09-18 20:16 +1000
              Re: Standardization process Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 14:51 +0400
                Re: Standardization process dxf <dxforth@gmail.com> - 2024-09-18 23:39 +1000
                Re: Standardization process Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 18:41 +0400
              Re: Standardization process Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 15:59 +0400
        Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 12:44 +0400
          Re: single-xt approach in the standard Gerry Jackson <do-not-use@swldwa.uk> - 2024-09-18 21:59 +0100
            Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-19 10:17 +0200
            Standard testsuite (was: single-xt approach in the standard) Ruvim <ruvim.pinka@gmail.com> - 2024-09-19 12:24 +0400
              Re: Standard testsuite (was: single-xt approach in the standard) albert@spenarnc.xs4all.nl - 2024-09-19 10:54 +0200
  Re: single-xt approach in the standard mhx@iae.nl (mhx) - 2024-09-17 12:15 +0000
    Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-17 17:04 +0400
      Re: single-xt approach in the standard minforth@gmx.net (minforth) - 2024-09-17 13:58 +0000
        Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-17 18:55 +0400
          Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-17 17:22 +0200
      Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-21 12:51 +1000
        Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-21 15:42 +0400
          Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-22 12:15 +1000
            Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-22 07:54 +0000
              Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-22 12:05 +0200
              Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-23 13:34 +1000
                Re: single-xt approach in the standard Anthony Howe <achowe@snert.com> - 2024-09-23 10:45 -0400
                Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-24 14:50 +1000
                Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-25 10:35 +1000
            Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-22 20:57 +0400
              Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-22 17:13 +0000
                Semantics as observable behavior (was: single-xt approach in the standard) Ruvim <ruvim.pinka@gmail.com> - 2024-09-22 23:53 +0400
                Re: Semantics as observable behavior (was: single-xt approach in the standard) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-22 21:04 +0000
                Re: Semantics as observable behavior Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 02:01 +0400
                Re: Semantics as observable behavior Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 11:36 +0400
              Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-22 21:34 +0200
                Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 00:02 +0400
                Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-23 09:40 +0200
                Re: single-xt approach in the standard minforth@gmx.net (minforth) - 2024-09-23 08:42 +0000
              Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-23 15:28 +1000
                Standard compliance for systems (was: single-xt approach in the standard) Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 10:56 +0400
                Re: Standard compliance for systems dxf <dxforth@gmail.com> - 2024-11-22 16:49 +1100
                Re: Standard compliance for systems minforth@gmx.net (minforth) - 2024-11-22 10:11 +0000
                Re: Standard compliance for systems mhx@iae.nl (mhx) - 2024-11-22 11:35 +0000
                Re: Standard compliance for systems minforth@gmx.net (minforth) - 2024-11-22 13:11 +0000
                Re: Standard compliance for systems mhx@iae.nl (mhx) - 2024-11-22 15:26 +0000
                Re: Standard compliance for systems dxf <dxforth@gmail.com> - 2024-11-23 11:54 +1100
                Re: Standard compliance for systems albert@spenarnc.xs4all.nl - 2024-11-23 14:09 +0100
                Re: Standard compliance for systems dxf <dxforth@gmail.com> - 2024-11-24 12:02 +1100
      Re: single-xt approach in the standard Stephen Pelc <stephen@vfxforth.com> - 2024-09-21 14:47 +0000
        Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-21 23:18 +0400
          Re: single-xt approach in the standard Stephen Pelc <stephen@vfxforth.com> - 2024-09-22 12:09 +0000
            Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-22 14:28 +0000
            Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-22 21:20 +0200
      Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-22 11:53 +0200
        Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 01:15 +0400
          Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-23 10:36 +0200
            Re: single-xt approach in the standard mhx@iae.nl (mhx) - 2024-09-23 09:32 +0000
              Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-23 13:57 +0200
              Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-23 17:02 +0000
                Re: single-xt approach in the standard mhx@iae.nl (mhx) - 2024-09-23 19:20 +0000
            Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 14:16 +0400
              Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-23 16:52 +0000
                Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-25 11:27 +0400
    Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-17 17:18 +0200
  Re: single-xt approach in the standard Anthony Howe <achowe@snert.com> - 2024-09-17 15:12 -0400
    Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-17 19:25 +0000
      Re: single-xt approach in the standard Anthony Howe <achowe@snert.com> - 2024-09-24 07:08 -0400
    Re: single-xt approach in the standard Stephen Pelc <stephen@vfxforth.com> - 2024-09-17 23:04 +0000
      Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 10:10 +0400
        Re: single-xt approach in the standard mhx@iae.nl (mhx) - 2024-09-18 06:38 +0000
          Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-19 12:26 +0400
    Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 14:34 +0400
      Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 16:41 +0400
      Re: single-xt approach in the standard Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-18 18:43 +0200
        Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-19 10:36 +0200
          Re: single-xt approach in the standard Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-20 14:58 +0200
  Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-17 21:15 +0000
  Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 12:15 +0400
  Re: single-xt approach in the standard peter.m.falth@gmail.com (PMF) - 2024-09-21 21:28 +0000
    Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-22 07:23 +0000
    Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-22 21:34 +0400

csiph-web