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
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
