Re: single-xt approach in the standard

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?

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