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

Liste des GroupesRevenir à cl forth 
Sujet : Standard compliance for systems (was: single-xt approach in the standard)
De : ruvim.pinka (at) *nospam* gmail.com (Ruvim)
Groupes : comp.lang.forth
Date : 23. Sep 2024, 07:56:46
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vcr3ff$25spg$9@dont-email.me>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla Thunderbird
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

Date Sujet#  Auteur
17 Sep 24 * single-xt approach in the standard78Ruvim
17 Sep 24 +* Re: single-xt approach in the standard15minforth
17 Sep 24 i`* Re: single-xt approach in the standard14Ruvim
17 Sep 24 i `* Re: single-xt approach in the standard13Anthony Howe
18 Sep 24 i  +* Re: single-xt approach in the standard7dxf
18 Sep 24 i  i`* Standardization process (was: single-xt approach in the standard)6Ruvim
18 Sep 24 i  i `* Re: Standardization process5dxf
18 Sep 24 i  i  +* Re: Standardization process3Ruvim
18 Sep 24 i  i  i`* Re: Standardization process2dxf
18 Sep 24 i  i  i `- Re: Standardization process1Ruvim
18 Sep 24 i  i  `- Re: Standardization process1Ruvim
18 Sep 24 i  `* Re: single-xt approach in the standard5Ruvim
18 Sep 24 i   `* Re: single-xt approach in the standard4Gerry Jackson
19 Sep 24 i    +- Re: single-xt approach in the standard1albert
19 Sep 24 i    `* Standard testsuite (was: single-xt approach in the standard)2Ruvim
19 Sep 24 i     `- Re: Standard testsuite (was: single-xt approach in the standard)1albert
17 Sep 24 +* Re: single-xt approach in the standard46mhx
17 Sep 24 i+* Re: single-xt approach in the standard44Ruvim
17 Sep 24 ii+* Re: single-xt approach in the standard2minforth
17 Sep 24 iii`- Re: single-xt approach in the standard1Ruvim
21 Sep 24 ii+* Re: single-xt approach in the standard28dxf
21 Sep 24 iii`* Re: single-xt approach in the standard27Ruvim
22 Sep 24 iii `* Re: single-xt approach in the standard26dxf
22 Sep 24 iii  +* Re: single-xt approach in the standard6Anton Ertl
22 Sep 24 iii  i+- Re: single-xt approach in the standard1albert
23 Sep 24 iii  i`* Re: single-xt approach in the standard4dxf
23 Sep 24 iii  i `* Re: single-xt approach in the standard3Anthony Howe
24 Sep 24 iii  i  +- Re: single-xt approach in the standard1dxf
25 Sep 24 iii  i  `- Re: single-xt approach in the standard1dxf
22 Sep 24 iii  `* Re: single-xt approach in the standard19Ruvim
22 Sep 24 iii   +* Re: single-xt approach in the standard5Anton Ertl
22 Sep 24 iii   i`* Semantics as observable behavior (was: single-xt approach in the standard)4Ruvim
22 Sep 24 iii   i `* Re: Semantics as observable behavior (was: single-xt approach in the standard)3Anton Ertl
22 Sep 24 iii   i  `* Re: Semantics as observable behavior2Ruvim
23 Sep 24 iii   i   `- Re: Semantics as observable behavior1Ruvim
22 Sep 24 iii   +* Re: single-xt approach in the standard4albert
22 Sep 24 iii   i`* Re: single-xt approach in the standard3Ruvim
23 Sep 24 iii   i `* Re: single-xt approach in the standard2albert
23 Sep 24 iii   i  `- Re: single-xt approach in the standard1minforth
23 Sep 24 iii   `* Re: single-xt approach in the standard9dxf
23 Sep 24 iii    `* Standard compliance for systems (was: single-xt approach in the standard)8Ruvim
22 Nov 24 iii     `* Re: Standard compliance for systems7dxf
22 Nov 24 iii      `* Re: Standard compliance for systems6minforth
22 Nov 24 iii       +* Re: Standard compliance for systems3mhx
22 Nov 24 iii       i`* Re: Standard compliance for systems2minforth
22 Nov 24 iii       i `- Re: Standard compliance for systems1mhx
23 Nov 24 iii       `* Re: Standard compliance for systems2dxf
24 Nov 24 iii        `- Re: Standard compliance for systems1dxf
21 Sep 24 ii+* Re: single-xt approach in the standard4Stephen Pelc
21 Sep 24 iii`* Re: single-xt approach in the standard3Ruvim
22 Sep 24 iii `* Re: single-xt approach in the standard2Stephen Pelc
22 Sep 24 iii  `- Re: single-xt approach in the standard1Anton Ertl
22 Sep 24 ii`* Re: single-xt approach in the standard9albert
22 Sep 24 ii `* Re: single-xt approach in the standard8Ruvim
23 Sep 24 ii  `* Re: single-xt approach in the standard7albert
23 Sep 24 ii   +* Re: single-xt approach in the standard3mhx
23 Sep 24 ii   i`* Re: single-xt approach in the standard2Anton Ertl
23 Sep 24 ii   i `- Re: single-xt approach in the standard1mhx
23 Sep 24 ii   `* Re: single-xt approach in the standard3Ruvim
23 Sep 24 ii    `* Re: single-xt approach in the standard2Anton Ertl
25 Sep 24 ii     `- Re: single-xt approach in the standard1Ruvim
17 Sep 24 i`- Re: single-xt approach in the standard1albert
17 Sep 24 +* Re: single-xt approach in the standard11Anthony Howe
17 Sep 24 i+* Re: single-xt approach in the standard2Anton Ertl
24 Sep 24 ii`- Re: single-xt approach in the standard1Anthony Howe
18 Sep 24 i+* Re: single-xt approach in the standard4Stephen Pelc
18 Sep 24 ii`* Re: single-xt approach in the standard3Ruvim
18 Sep 24 ii `* Re: single-xt approach in the standard2mhx
19 Sep 24 ii  `- Re: single-xt approach in the standard1Ruvim
18 Sep 24 i`* Re: single-xt approach in the standard4Ruvim
18 Sep 24 i +- Re: single-xt approach in the standard1Ruvim
18 Sep 24 i `* Re: single-xt approach in the standard2Hans Bezemer
19 Sep 24 i  `- Re: single-xt approach in the standard1albert
17 Sep 24 +- Re: single-xt approach in the standard1Anton Ertl
18 Sep 24 +- Re: single-xt approach in the standard1Ruvim
21 Sep 24 `* Re: single-xt approach in the standard3PMF
22 Sep 24  +- Re: single-xt approach in the standard1Anton Ertl
22 Sep 24  `- Re: single-xt approach in the standard1Ruvim

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal