From: the.beez.speaks@gmail.com
On 13-02-2026 12:35, albert@spenarnc.xs4all.nl wrote:
> In article <698d205a$1@news.ausics.net>, dxf wrote:
>> On 12/02/2026 12:34 am, Hans Bezemer wrote:
>>> On 11-02-2026 01:21, dxf wrote:
>>>> On 11/02/2026 4:48 am, jkn wrote:
>>>>> ...
>>>>> I have no skin in this game at all - I am basically an observer of both
the language,
>>>>> and this newsgroup. But it seems strange to me that in a language that
is so
>>>>> self-describedly flexible as Forth, the operation of the inner
interpreter should
>>>>> not itself be open to flexibility.
>>>>
>>>> IIRC recognizers was a c.l.f invention. Each forth, it was noted, had
its own way
>>>> of integrating floating-point into the system - fp being an 'optional
extension'
>>>> of Forth-94. Typically integration was achieved through hooks the
system designer
>>>> had purposely built into system. Forth-94 had already defined how the
forth
>>>> interpreter should handle fp numbers. Parsing words F# etc were not an
option.
>>>>
>>>> WIBN (wouldn't it be nice) it was argued if these hooks into the
interpreter could
>>>> be made portable. It caught the imagination of sufficient users (in
forth there's
>>>> little distinction between user and system-designer) and the rest is
history.
>>>> Recognizers were sufficiently complicated prompting more justification
than fp (1)
>>>> in order to sell it. It was 'a solution in search of a problem'. From
that came
>>>> the idea that forth should be able to parse *anything* - however unlikely
or little
>>>> used.
>>>>
>>>> (1) While fp integration prompted recognizers, recognizers were never a
complete
>>>> solution. Integrating fp into a system often requires more than simply
making the
>>>> interpreter recognize fp numbers. System-specific hooks remain.
>>>>
>>>
>>> Extending the functionality of already defined words (in previous
wordsets) was always a weak point of ANS-94. I don't know if other language
>> standards use this, but I don't feel comfortable with "redefining" or
"extending" words.
>>>
>>> BTW, S" is one of the few examples of words that are not stateless
(contrary to CHAR and [CHAR], ' and ['], ." and .( etc.).
>>>
>>> They could have spared us a lot of trouble defining S( - or whatever. But
consistency has never been Forth's strong point, unfortunately.
>> It's always trends that are aborted half way, because the maintenance
efforts are getting out of hand.
>>>
>>> This discrepancy between pragmatism and "a brave new world" becomes
painfully clear when reading section 12.3.7:
>>>
>>> "If the Floating-Point word set is present in the dictionary and the
current base is DECIMAL, the input number-conversion algorithm shall be
>> extended to recognize floating-point numbers."
>>>
>>> Which means you have to do an overhaul of the text interpreter. Which is a
HORRIBLE requirement!
>>>
>>> And its rationale:
>>>
>>> "A.12.3.7 Text interpreter input number conversion. The Technical
Committee has more than once received the suggestion that the text
>> interpreter in Standard Forth systems should treat numbers that have an
embedded decimal point, but no exponent, as floating-point numbers
>> rather than double cell numbers. This suggestion, although it has merit,
has always been voted down because it would break too much existing
>> code; many existing implementations put the full digit string on the stack
as a double number and use other means to inform the application of
>> the location of the decimal point."
>>>
>>> It would have been better if such requirement had NOT existed and (as ugly
as it is) S" 12.34e" >FLOAT had remained the only accepted way to
>> enter an FP number - OR a word like F% or F# had been brought into
existence for the time being.
>>
>> I would say by the time ANS-TC began its deliberations the die had already
been cast.
>> The 'Standard Floating Point Extension' published in 1985 by the Forth
Vendors Group
>> (LMI and Micromotion with input from several vendors) required input in the
form:
>>
>> If the floating point extension word set has been overlaid onto a
>> 83-Standard Forth system, a string of the following form will be
>> compiled or interpreted as a real number:
>>
>> nnnn.nnnExx
>>
>> The "E" signifier is mandatory to force the conversion of a real
>> number. The presence of numeric digits before or after the "E"
>> is not required by this specification but may be mandatory in
>> some implementations. A "-" sign may precede both the mantissa
>> and the exponent, a leading "+" sign is also permissible on the
>> exponent. A decimal point is optional and occur anywhere in the
>> mantissa. For example, all of the following numbers are legal:
>>
>> -.0001E5
>> 100.0E+0
>> 1000.E-15
>>
>> After Forth-83 which split vendors, ANS-TC wasn't going to do anything that
drew the
>> ire of an existing user base. One only has to look at the flack Forth-94
received
>> when a section of existing locals users didn't get what they were expecting.
>>
>>> I still think that meddling with the text interpreter is a big no-no and
an invitation to disaster. Never leave to a computer that which a
>> programmer can signify as his intent. Although I'm still not dancing on the
table, that is at least one of the characteristics of Alberts
>> proposal (and it leaves the text interpreter largely intact!)
>>
>> I get it but IMO f/p isn't something one simply LOADs - even if Forth-94
sold it that
>> way as a nod to minimalists. With the exception of folks like me (and
perhaps you)
>> who want to be able to load a variety of f/p packs, f/p is there when one
boots forth.
>> What the eyes don't see, the heart doesn't grieve.
>>
>
> With the diminishing importance of double integers, I would support
> the idea if requiring a decimal point as the start *and* end of a double
> precision number.
> .10000000000000000000.
> Now any number containing one decimal point can safely be considered a
> floating point number.
> Also E as the exponent is a design error. The twiggle is ideal,
> it support a 126 base. BASE 16 is ideal to eliminate rounding errors
> during transfers over asci channels.
>
> Groetjes Albert
When I designed 4tH, I got rid of double numbers (and consequently,
mixed numbers as well). Yeah, they have their use in the 16 bit era -
but not anymore. FYI - that was 1994.
In the 64-bit era, I think we could get rid of double numbers
altogether. Dump the whole thing in a separate wordset and be done with
it. Clean up CORE.
"Yeah, but don't you know how much code would get broken?" Yeah, I've
heard that song before. Let's keep dragging all that old stuff along
till eternity. You can never have enough technical depth, can you.
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
