From: dxforth@gmail.com   
      
   On 23/09/2024 4:56 pm, Ruvim wrote:   
   > 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.   
      
   Code written for a unified stack works on every system.  The problem rather was   
   those hell-bent against a unified fp stack.  It wasn't enough ANS permitted   
   them   
   to write separate stack fp code.  They wanted the unified stack fp gone - out   
   of   
   the picture.  In 2012 a separate fp stack isn't an option - it's a commandment:   
      
     12.3.3 Floating-point stack   
     ...   
     The floating-point stack _shall_ be separate from the data and return stacks.   
      
   When the Bible said:   
      
     "You _shall_ have no other gods before Me"   
      
   there was no 'environmental restriction' in the footnotes allowing other gods   
   or   
   none as that would render the commandment meaningless.   
      
   > ...   
   > 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.   
      
   This again is a mess since:   
      
     S" abc"  S" def"  S" ghi"   
      
   in a 'standard program' falls outside the minimum and would not be   
   considered portable.  Yet a 'standard system' that cannot do:   
      
     S" abc"  S" def"  S" ghi"   
      
   is deemed by 2012 to have an 'environmental restriction' since:   
      
     11.3.4  Other transient regions   
     ... "RAM-limited systems may have environmental restrictions on the   
     number of buffers and their lifetimes."   
      
   Both Forth-94 and 2012 define 'environmental restriction' as applying   
   to systems which 'cannot meet the minimum values set out in section 3'.   
      
   AFAICS 'two' is the minimum number of S" interpretive buffers specified   
   by 2012.  Such a system should thus be considered entirely compliant.   
   OTOH a 'unified fp stack' is not any kind of minimum.  Rather it ignores   
   12.3.3 in the provisioning of a separate fp stack.  Such a system is   
   outright non-compliant.   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)