[GHC] #11170: (read ".9") :: Double unable to parse

[GHC]

#11170: (read ".9") :: Double unable to parse
-------------------------------------+-------------------------------------
        Reporter:  varosi            |                Owner:
            Type:  bug               |               Status:  closed
        Priority:  normal            |            Milestone:
       Component:  Core Libraries    |              Version:  7.10.2
      Resolution:  wontfix           |             Keywords:  Read, report-
                                     |  impact
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by carter):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 1) i understand the nature of your request, you do not need to explain it
 further

 2) the purpose of read / show are to provide basic round tripping
 facilities for naive debugging / printing of haskell data structures,

 3) for complicated data structures, accepting ".9" as valid would create
 some room for more ambiguity in parsing

 4) as a further piece of anecdata for why this would be a terrible change,
 in a work code base, the fact that attoparsec accepts floats in this
 format created some incredibly hard to resolve bugs in a streaming parsing
 facility. So from that perspective since this seems to mostly an
 aesthetical feature request, i suggest you write you own either a) read
 instance for a newtype'd double, OR  use a different parsing library that
 suites your goals, such as attoparsec :)

 for core core data types such as floating point, breaking changes to how
 built in parsing facilities work must be done with utmost consideration.

 I actually took the time to check the 2008 IEEE Floating point standard,
 and it doesn't specify this. The only format support that is mandated by
 the IEEE 2008 floating point standard is support for reading/writing
 floating point numbers in hexadecimal notation.
 The specification therein does allow terms of the form "0x.9" or "0X.9",
 but those are MUCH MUCH less ambiguous than ".9" in terms of possible
 parsing interpretations, and is infact a very very reasonable part of the
 standard because that is precisely a finite representation that has zero
 rounding between the internal binary representation of finite numbers and
 a hexadecimal floating point string presentation.

 Several folks have now all agreed that for a miscellany of reasons that
 your feature request is invalid.
 It would be valid to explore adding hexadecimal floating point read/show
 support, though that could itself have parsing implications that'd need be
 understood, but doesn't face the same parsing ambiguities, AND is actually
 specified by the underlying floating point standard. (just because the C11
 language standard specifies that ".1" is a valid floating point literal
 doesn't justify that we do, and the read instances for haskell base SHOULD
 / MUST match what are acceptable literals for the source, and because the
 code for read/show does't change with the language extensions enabled,  it
 MUST match what is specified in the haskell language standard)


 point of record: haskell language defines float lexical terms as

 {{{

 float → decimal . decimal [exponent]
     |  decimal exponent
 }}}


 likewise, the hexformat in the 2008 IEEE floating point standard is

 {{{
 sign
 digit
 hexDigit hexExpIndicator hexIndicator hexSignificand decExponent
 hexSequence
 [+ −]
 [0123456789]
 [0123456789abcdefABCDEF]
 [Pp]
 "0" [Xx]
 ( {hexDigit} * "." {hexDigit}+ | {hexDigit}+ "." | {hexDigit}+ )
 {hexExpIndicator} {sign}? {digit}+
 {sign}? {hexIndicator} {hexSignificand} {decExponent}


 }}}



               where each line is a name followed by a rule in which
 ‘[...]’ selects one of the terminal characters listed between the
 brackets, ‘{...}’           refers to an earlier named rule, ‘(... | ... |
 ...)’ indicates a choice of one of three alternatives, straight double
 quotes enclose a terminal character, ‘?’ indicates that there shall be
 either no instance or one instance of the preceding item, ‘*’ indicates
 that there shall be zero or more instances of the preceding item, and ‘+’
 indicates that there shall be one or more instances of the preceding item.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11170#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler