[erlang-questions] Re: floating point syntax

[Richard O'Keefe]

On Apr 20, 2010, at 9:47 PM, Anthony Shipman wrote:

> On Tue, 20 Apr 2010 07:16:02 am Robert Virding wrote:
>> IIRC it was probably more that we/I just didn't see the need to be
>> able to write the shortened forms. It isn't that it is much extra you
>> have to write. :-)
>>
>> Robert
>
> When parsing numbers for other languages it would be nice to be able  
> to use
> fread() to parse them instead of writing my own. Some sort of ~N  
> form to read
> a number, integer or floating point, in the usual syntax would be  
> nice.

What _is_ the "usual syntax"?
Here's a floating point number: 1.23@REDACTED           (Burroughs Algol)
Here's a floating point number: 1.23E45_DOUBLE    (Fortran)
Here's a floating point number: 1.23D45           (Fortran, Lisp,  
Smalltalk)
Here's a floating point number: 1.23e45L          (C)
Here's a floating point number: ~12.34            (ML)
Here's a floating point number: 1_234_567.0       (Ada, OCaml)
Here's a floating point number: 1 234 567.0       (Fortran, Algol 60,  
Algol 68)
Here's a floating point number: 0x12.34p45        (C)
Here's a floating point number: 101.101E2B	  (PL/I)
Here's a floating point number: 1.23Q45           (ANSI Smalltalk)

For what it's worth, here's the "usual syntax" for floats from the
ANSI Smalltalk standard:

float ::= mantissa [exponentLetter exponent]
mantissa ::= digits ’.’ digits
digits ::= digit+
exponent ::= [’-’]decimalInteger
exponentLetter ::= ’e’ | ’d’ | ’q’

Except for letting the exponent letter vary to indicate the
precision of the number (single, double, double extended),
this is pretty traditional.  (Even "d" is traditional.)
Erlang is not alone in requiring a digit each side of the dot.

There is so much variation between programming languages that
it is extremely hard to cover all of them (and believe me, I've
tried).  True, Fortran allows numbers with a digit on only one
side of the dot, but it also allowed spaces inside numbers; is
_that_ "usual syntax"?

One really important issue these days is allowing numbers written
by people or programs using the comma as the radix point.

There are obvious advantages to "being generous in what you accept",
but we cannot just appeal to "usual syntax" to determine what that
should be.  We need something more explicit.