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.   
      
   >- POB contents are built up from right to left, making concatenation   
   >   user hostile   
   Make that a "minor inconvenience".   
      
   >- only one buffer available to the programmer   
   See ALLOCATE.   
   >- cannot set POB size   
   See ALlOCATE.   
   >- buffers not nestable   
   See ALLOCATE.   
   >- POB contents can only be accessed by #> which terminates things   
   ???   
   >- system words such as .S may use the POB, thus hindering debugging   
   See nesting   
   >- the system need not check the POB for overflow   
   See ALLOCATE   
   >   
   >Some of these can be improved in a Forth system but software using the   
   >improvements may not be portable between systems.   
   They need not be. Only the spec's have to be updated.   
   It has been debunked numerous times, that adhering to a   
   common specification doesn't require a portable implementation.   
   >   
   >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.   
      
   If you want printf compatibility, why not just import a c-library?   
      
   >--   
   >Gerry   
   >   
   Groetjes Albert   
   --   
   Don't praise the day before the evening. One swallow doesn't make spring.   
   You must not say "hey" before you have crossed the bridge. Don't sell the   
   hide of the bear until you shot it. Better one bird in the hand than ten in   
   the air. First gain is a cat purring.            - the Wise from Antrim -   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)