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-22 20:57 +0400
Organization	A noiseless patient Spider
Message-ID	<vcpi98$25spg$1@dont-email.me> (permalink)
References	(1 earlier) <1a3ebf77c1ed8926d455a268e1309fe0@www.novabbs.com> <vcbuog$3etuk$3@dont-email.me> <66ee34a2$1@news.ausics.net> <vcmbf2$1ifml$1@dont-email.me> <66ef7dc7$1@news.ausics.net>

Show all headers | View raw

On 2024-09-22 06:15, dxf wrote:
> On 21/09/2024 9:42 pm, Ruvim wrote:
>> On 2024-09-21 06:51, dxf wrote:
>>> On 17/09/2024 11:04 pm, Ruvim wrote:
>>>>
>>>> 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 effectively means that the classic single-xt approach is impossible for a standard system.
>>>
>>> Forth-94 section A.1.2 indicates the X3J14 Technical Committee were guided by
>>> several considerations including:
>>>
>>>    "Cost of compliance
>>>     This goal includes such issues as common practice, how much existing code
>>>     would be broken by the proposed change, and the amount of effort required to
>>>     bring existing applications and systems into conformity with the Standard.
>>>
>>>     Utility
>>>     Be judged to have sufficiently essential functionality and frequency of use
>>>     to be deemed suitable for inclusion."
>>>
>>> As 200x has since sought fit to require:
>>>
>>> - a separate fp stack
>>> - quote-delimited character interpretation ('A')
>>> - S" support two interpretive buffers
>>
>> This does not exclude the classic single-xt approach.
>>
>> Do you mean that these points do not meet the "Cost of Compliance" and "Usefulness" considerations?
>   
> IMO small systems are better off with Forth-94.  And if they're doing that
> they'll be free to implement things actually useful to them as the pressure
> to conform has passed.

Most words are optional. And even the CORE word set is not obligated for 
a Standard System Subset.

The section "5.1.1 System compliance" of Forth-2012 says: "An otherwise 
Standard System that provides only a portion of the Core words is a 
Standard System Subset. An otherwise Standard System (Subset) that fails 
to comply with one or more of the minimum values or ranges specified in 
3 Usage requirements and its sub-sections has environmental restrictions."

The main pressure is that if a standard system provides a word in the 
FORTH-WORDLIST with a standard name, that word shall behave as specified 
in the standard.  But this is a very light pressure, because if you do 
not want to implement the standard behavior for a word, just give the 
word another name, or place it in another word list.

>>> nobody that has complied should be worried about excluding systems that use a
>>> state-smart S" .
>>
>> I do not understand how this follows from the above. My system complies with the above points, and it is a single-xt system. Why I should not be worried?
>>
>> Moreover, excluding the single-xt approach does *nothing* useful for programs.
> 
> Same for the items I listed.

It is not the same.

1) A separate fp stack makes programs far simpler comparing with 
programs that comply the fp stack is separate or united with the data 
stack, and moderately simpler than the programs with the environmental 
dependency that the floating-point numbers are kept on the data stack.

NB: Keeping floating-point numbers on the data stack does not make a 
Forth system non-standard, but it merely adds an environmental 
restriction to this system, see the section "12.4.1.4 Environmental 
restrictions" in Forth-2012.

2) Quote-delimited character interpretation ('A') makes programs 
simpler, this seems obvious.

3) Two buffers for interpretive `s"` makes debugging simpler, because 
you can test words like `rename-file` interactively, see "A.17.3.4 Other 
transient regions" in Forth-2012.

> The real question is what major system still uses
> single-xt and would object were it excluded.
> 

It is not only the implementers of major systems who are allowed to object.

Some arguments:

- Most Forth systems are single-xt systems. Why we should reject them, 
without any profit for programs?

- All standard programs are single-xt programs (in the part of 
user-defined words). Why we should remove the way to document this 
programs/words in the standard terms of interpretation semantics, 
compilation semantics and execution semantics?

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