Standard compliance for systems (was: single-xt approach in the standard)

From	Ruvim <ruvim.pinka@gmail.com>
Newsgroups	comp.lang.forth
Subject	Standard compliance for systems (was: single-xt approach in the standard)
Date	2024-09-23 10:56 +0400
Organization	A noiseless patient Spider
Message-ID	<vcr3ff$25spg$9@dont-email.me> (permalink)
References	(3 earlier) <66ee34a2$1@news.ausics.net> <vcmbf2$1ifml$1@dont-email.me> <66ef7dc7$1@news.ausics.net> <vcpi98$25spg$1@dont-email.me> <66f0fc6c$1@news.ausics.net>

Show all headers | View raw

On 2024-09-23 09:28, dxf wrote:
> On 23/09/2024 2:57 am, Ruvim wrote:
...
>> 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.
> 
> I hadn't seen that.  Forth-94 stated floating-point stack was "the default".
> If the only change is that the latter is clarified, then no harm done.
> Implementing separate stack on an 8-bit cpu would be expensive and a
> performance killer.  

> As to being "far simpler" to program, similar appeals
> are made in respect of locals.
> I make it a point to program as if I had a
> unified stack just to see if the claim is true.

A real problem was to create programs that work with floating point 
numbers and would work correctly both on a unified fp stack and on a 
separate fp stack.

See the section "C.7.2 Separate Floating-point Stack is now Standard" in 
Forth-2012 <https://forth-standard.org/standard/diff#subsection.C.7.2>


> 
>> 2) Quote-delimited character interpretation ('A') makes programs simpler, this seems obvious.
> 
> Only thing obvious is it's an import from other languages and redundant.
> Forth Inc stated they didn't agree with it but eventually provided it.
> 

Using `'x'` is simpler and shorter than `[char] x` or `char x` depending 
on the context.

And even if you redefine `[char]` to provide the expected interpretation 
semantics, like:

   : [char] state @ if postpone [char] else char then ; immediate

`[char] x` is still longer than `'x'` and provides no additional benefit 
to programs.



>> 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.
> 
> I have  >PAD ( adr u -- adr2 u )  for that.  Uses existing resources and is
> more flexible.
> 

The phrase:

   s" foo" s" bar" rename-file .

is simpler than:

   s" foo" >pad s" bar" rename-file .

What advantages does the latter provide to users over the former?



If a Forth system is so limited in memory that it cannot provide two 
buffers for `s"`, it *might* provide only one buffer and declare the 
corresponding environmental restriction according to the sections:

- 5.1.1 System compliance
| 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.

- 5.1.2 System labeling
| The phrase "with Environmental Restrictions" shall be
| appended to the label of a Standard System (Subset) that
| has environmental restrictions.

- 11.3 Additional usage requirements, 11.3.4 Other transient regions
| The system provides transient buffers for `S"` and `S\"`
| regions strings. These buffers shall be no less than 80
| characters in length, and there shall be at least two buffers.




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