Re: single-xt approach in the standard

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