Float literals

Float literals

[Edgar Friendly]

In writing a syntax highlighter for Ocaml, I've dug into the code for
float literals:

let float_literal =
  ['0'-'9'] ['0'-'9' '_']*
  ('.' ['0'-'9' '_']* )?
  (['e' 'E'] ['+' '-']? ['0'-'9'] ['0'-'9' '_']*)?

This matches what the reference manual says about float literals:

float-literal	::=	[-] (0…9) { 0…9∣ _ } [. { 0…9∣ _ }] [(e∣ E) [+∣ -]
(0…9) { 0…9∣ _ }]

But it doesn't match some expectations I have about float literals.  The
following are all float literals:

3.14      (* no problem here *)
6.022E23  (* no problem here *)
9.109e-31 (* still no problem *)
2.        (* a float - blank decimal part *)
1e6       (* an integer?  no, a float without a .  Problem.*)
13        (* valid as a float, according to the above definition *)

Does anyone else find the last two cases kind of odd?  Maybe it's not a
big deal because the 1e6 is scientific notation, which is float-y, and
the last one is always parsed as an integer, I assume because of
precedence in the lexing functions.

E.

Re: [Caml-list] Float literals

[Erik de Castro Lopo]

Edgar Friendly wrote:

> But it doesn't match some expectations I have about float literals.  The
> following are all float literals:
> 
> 3.14      (* no problem here *)
> 6.022E23  (* no problem here *)
> 9.109e-31 (* still no problem *)
> 2.        (* a float - blank decimal part *)
> 1e6       (* an integer?  no, a float without a .  Problem.*)
> 13        (* valid as a float, according to the above definition *)
> 
> Does anyone else find the last two cases kind of odd?

I do not find the second last case odd (all languages I have used
consider that a float), but I do for the last one.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Neither noise nor information is predictable."
  -- Ray Kurzweil

Re: [Caml-list] Float literals

[Robert Roessler]

Edgar Friendly wrote:
> 1e6       (* an integer?  no, a float without a .  Problem.*)
> 13        (* valid as a float, according to the above definition *)
> 
> Does anyone else find the last two cases kind of odd?  Maybe it's not a
> big deal because the 1e6 is scientific notation, which is float-y, and
> the last one is always parsed as an integer, I assume because of
> precedence in the lexing functions.

There isn't (to me) anything weird about this... from 6.1 in the 
reference manual on "Floating-point literals":

"The decimal part or the exponent part can be omitted, but not both to 
avoid ambiguity with integer literals."

And, as you suggest, in practice it isn't an issue either - a lexer 
will try to see a numeric literal as an int as long as it legally 
still can constitute an int.  But assuming we are still recognizing a 
base 10 literal, a *letter* that isn't 'l', 'L', or 'n' had better be 
an 'e' or 'E' (so that it may still be a float)... or you have an 
invalid token. ;)

Robert Roessler
roessler@rftp.com
http://www.rftp.com

Re: [Caml-list] Float literals

[Jon Harrop]

On Tuesday 26 June 2007 21:38:26 Erik de Castro Lopo wrote:
> I do not find the second last case odd (all languages I have used
> consider that a float), but I do for the last one.

Would you like:

  float_of_string "55378008"

to work?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?e

Re: [Caml-list] Float literals

[Edgar Friendly]

Jon Harrop wrote:
> On Tuesday 26 June 2007 21:38:26 Erik de Castro Lopo wrote:
>> I do not find the second last case odd (all languages I have used
>> consider that a float), but I do for the last one.
> 
> Would you like:
> 
>   float_of_string "55378008"
> 
> to work?
> 
Yes, I would.  Somehow there's a difference between user input and
program code.  For user input, you want to be pretty permissive in what
you accept.  I guess you could force the programmer to write
  try
    float_of_string str
  with
    Failure _ ->
      int_of_string str
but there's all sorts of corner cases in that, from alternate bases to
range issues.

But technically it's a violation of spec, as the note (that I missed
before) in the float-literal definition about requiring either an
exponent or a decimal part of the number should apply here too.