From: do-not-use@swldwa.uk   
      
   On 30/04/2024 09:38, albert@spenarnc.xs4all.nl wrote:   
   > In article ,   
   > Gerry Jackson   wrote:   
   >> On 29/04/2024 17:22, Paul Rubin wrote:   
   >>> dxf  writes:   
   >>>> For reasons one can only speculate Forth Standards have by and large   
   ignored   
   >>>> numeric string output.   
   >>>   
   >>> There is the <# ... #> machinery.  Does that count?   
   >>   
   >> It's a nice idea but the restrictions around it and the specified   
   >> implementation render it unsuitable for building upon it if you want to   
   >> write portable software. Faults with it are:   
   >>   
   >> - the pictured output buffer (POB) may be transient, can be corrupted by   
   >>    the system e.g. being  moved or overwritten   
   >   
   > This is not a fault with <#. You can easily make it work with   
   > ALLOCATE.   
      
   So given a Forth system suppose I allocate a buffer for use with the <#   
   family - how do I make the existing <# definitions use that buffer   
   without re-defining <# etc?   
      
   >   
   >> - POB contents are built up from right to left, making concatenation   
   >>    user hostile   
   > Make that a "minor inconvenience".   
      
   I don't think so   
      
   >> - only one buffer available to the programmer   
   > See ALLOCATE.   
      
   So given a Forth system I allocate an additional buffer for use with the   
   <# family - how do I make the existing <# definitions use that buffer   
   without re-defining <# etc?   
      
   >> - cannot set POB size   
   > See ALlOCATE.   
      
   So given a Forth system I .... how do I ...   
      
   >> - buffers not nestable   
   > See ALLOCATE.   
      
   >> - POB contents can only be accessed by #> which terminates things   
      
    > ???   
      
   How do you see what the buffer contains without using #>  when you don't   
   even know the starting address?   
      
   >> - system words such as .S may use the POB, thus hindering debugging   
   > See nesting   
      
   If a Forth system uses the POB for implementing .S how do I stop it   
   doing so without redefining .S (easy to do I admit).   
      
   >> - the system need not check the POB for overflow   
   > See ALLOCATE   
   >>   
      
   So given a Forth system I .... how do I ...   
      
      
   >> Some of these can be improved in a Forth system but software using the   
   >> improvements may not be portable between systems.   
      
   Did you not read this bit before your knee-jerk reaction above? No I   
   thought not   
      
   > They need not be. Only the spec's have to be updated.   
      
   Yeah sure - listen to the howls of outrage when changes to the ANS   
   standard are suggested particularly when they refer to things present   
   from the original implementations of Forth.   
      
   > It has been debunked numerous times, that adhering to a   
   > common specification doesn't require a portable implementation.   
      
   What has a portable implementation got to do with it, my comments were   
   about the using an existing Forth system that implements the <# family   
   doing nasty things that the standard permits such as moving the buffer   
   without you knowing.   
      
   >>   
   >> I've written my own version of <# etc, with the '#' replaced by '~',   
   >> that does not have the above problems. It has:   
   >>   
   >> new-buffer ( "name" xt ca u ~buf-size -- ) create a new format buffer   
   >> <~  ( -- ) open a format buffer   
   >> ~>  ( -- ca u ) get contents of the current buffer, can be added to (has   
   >>      synonym ~@   
   >> ~><~ ( -- ca u ) get contents of buffer, close it and open another   
   >> ~hold ( ch -- ) with synonym ~c+   
   >> ~holds ( ca u -- ) with synonym ~+   
   >> ~fill ( n ch -- )   
   >>   
   >> ~w ( n -- ) set a field width   
   >> ~r ( +n -- ) set field width and right justify next conversion   
   >> ~l ( -n -- ) set field width and left justify next conversion   
   >> ~uc ( -- ) set upper case   
   >> ~lc ( -- ) set lower case   
   >> ~d ( d -- ) convert signed double integer   
   >> ~i ( n -- ) convert signed integer   
   >> ~ud ( ud ) convert unsigned double integer   
   >> ~ui ( u -- ) convert unsigned integer   
   >> ~s  ( ca u -- ) hold string subject to any justification etc   
   >> ~c  ( ch  -- ) hold character subject to any justification etc   
   >>   
   >> I've used these as primitives for integer sprintf implementations   
   >> intending (when I get time and interest) to extend it to a floating   
   >> point sprintf   
   >   
   > You have yet to convince that these cannot be upwards compatible.   
      
   Upwards compatible with what? I wasn't intending them to be compatible   
   with anything.   
      
   >   
   > If you want printf compatibility, why not just import a c-library?   
   >   
      
   Where's the fun in that?   
      
   --   
   Gerry   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)