From: sjack@dontemail.me
dxf wrote:
> On 30/04/2024 7:40 pm, mhx wrote:
>> dxf wrote:
>>
>>> On 30/04/2024 2:22 am, 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?
>>
>>> Only as a missed opportunity. There's no cheaper way of adding string
>>> functions than the following and it was amiss of the Standard not to
>>> offer it.
>>
>>> \ Print string right-justified in a field of width chars
>>> : S.R ( adr len width -- ) over - spaces type ; ( eForth)
>>
>>> \ Numeric string output
>>> : (D.) ( d -- adr len ) tuck dabs <# #s rot sign #> ;
>>> : (U.) ( u -- adr len ) 0 (d.) ;
>>> : (.) ( n -- adr len ) s>d (d.) ;
>>
>>> \ Forth-79/83/94
>>> : D. ( d -- ) (d.) type space ;
>>> : U. ( u -- ) 0 d. ;
>>> : . ( n -- ) s>d d. ;
>>> : D.R ( d w -- ) >r (d.) r> s.r ;
>>> : U.R ( u w -- ) 0 swap d.r ;
>>> : .R ( n w -- ) >r s>d r> d.r ;
>>
>> The only words that are necessary to define these on your own are
>> <# # #> DABS and SIGN. There is a reason to define these in the
>> Standard: the hardware details of a number need to be known if you want to
do it yourself in a portable way. The other reason
>> is probably that double precision is needed to implement this,
>> but the Double-Number word set is optional.
>>
>> So far for speculation.
>
> iForth users don't need to speculate since (D.) (.) etc. are provided for
them.
>
>
>
>
Hope I didn't kill your article. Had made correction to mine and tried
to kill original but it looked to kill yours and alberts as well.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
