Fixed issue #12 Parsing "." results in Debug crash

[MikaelMayer]

Fixed issue #33 parsing leading zeroes Fixed issue #12 Parsing "." results in Debug crash

[MikaelMayer]

Note: I did not test this code. Can you please tell me if it is valid, or how to test it?

[MikaelMayer]

To be clear about this pull request, I did the following changes:

• I removed the supposition that numbers should start with a digit > 0. Leading zeroes should be parsed and the string conversion String.toFloat works perfectly with them. This correct an unfair bias: leading zeroes were parsed differently than trailing zeroes.
• I made it sure that things starting with e or E are NOT parsed as float
• The test for failure (dotOffset == offset && (result == dotOffset + 1 || Prim.isSubChar isE (dotOffset + 1) source)) means the following:
  • The first predicate states that the parse started with a non-digit - must be a dot because it cannot be 'e'
  • The second disjunction predicate tests that result either
    • parsed only one ASCII char, therefore just a dot, which should not parse as a float
    • parsed two or more ASCII char, and testing that the char after the dot is not an exponent sign, because ".e" or ".e1" are not float

This fixed https://github.com/elm-tools/parser/issues/17 as well because floats cannot start with "e".

The only potential problem I now see are for numbers like "1.0e" which will still cause the debug crash and should not be parsed as float.

[MikaelMayer]

Ok I fixed the potential problem. I add the guard that if the parse ends with an "e", it returns an error instead of crashing.