Re: inconsistent behavior of >FLOAT

Anton Ertl wrote:
"Ed" <nospam@xxxxxxxxxxx> writes:
Since we're on the subject of inconsistent behaviour of >FLOAT , I'll
throw in another. 12.6.1.0558 >FLOAT says:

"... If the string represents a valid floating-point number in the syntax
below, its value r and true are returned. If the string does not represent
a valid floating-point number only false is returned. ..."

I interpret that as: if the string does not match the syntax given then false
must be returned.

Given that at least the part about the string of blanks is optional,
it seems to me that the intention was that systems should at least
recognize the specified syntax as FP numbers, but that it may (and
sometimes "should") also accept other syntax (such as a string of
blanks) as FP numbers. Note that it does not say

|If the string does not represent a valid floating-point number _in
|the syntax below_ only false is returned.

Please note the introductory info in A.12.6.1.0558 >FLOAT:

">FLOAT enables programs to read floating-point data in legible ASCII format. It accepts a *much broader syntax* than does the text interpreter since the latter defines rules for composing source programs whereas >FLOAT defines rules for accepting data. >FLOAT is defined as broadly as is feasible to permit input of data from ANS Forth systems *as well as* other widely used standard programming environments"

(emphasis added) As I noted in another post in this thread last night, >FLOAT is not intended as a primitive or underlying component of the text interpreter, but rather a more liberal input mechanism intended to convert data from all kinds of sources that the Forth programmer may not have any control over. This is why its specification is loose. If you tighten it up a lot more, it may lose some of its usefulness.

That said, the issue of what to do with all blanks deals with the expectations of the Forth program, and it's reasonable to clarify that now. 15 years ago there wasn't enough "common practice" with FP to do that.

The issue of an *empty string* however, is something else. IMO that is an error, and should be treated as an "ambiguous condition".

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================
.

Relevant Pages

  • Re: inconsistent behavior of >FLOAT
    ... If the string represents a valid floating-point number in the syntax ... least* what the Standard specifies, or *only* what the Standard specifies? ... I expect>FLOAT to be solid, ...
    (comp.lang.forth)
  • Re: inconsistent behavior of >FLOAT
    ... If the string represents a valid floating-point number in the syntax ... if the string does not match the syntax given then false ... The question is, do you want systems to accept *at least* what the Standard specifies, or *only* what the Standard specifies? ...
    (comp.lang.forth)
  • Re: inconsistent behavior of >FLOAT
    ... If the string represents a valid floating-point number in the syntax ... if the string does not match the syntax given then false ... M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html ...
    (comp.lang.forth)
  • Re: inconsistent behavior of >FLOAT
    ... If the string represents a valid floating-point number in the syntax ... if the string does not match the syntax given then false ... Please note the introductory info in A.12.6.1.0558>FLOAT: ...
    (comp.lang.forth)
  • Re: State of Forth 200x
    ... An attempt is made to convert the string specified by c-addr and u to ... floating-point number in the syntax below, its value r and true are ... If the string does not represent a valid floating-point number ...
    (comp.lang.forth)