[ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals

Joachim Breitner mail at joachim-breitner.de
Tue Feb 28 17:58:11 UTC 2017


Hi,

I think that's fine, and the benefits outweigh the downsides.

This is treading on CLC space a bit, though. Should we coordinate with them?

Joachim 



Am 28. Februar 2017 09:30:16 PST schrieb Iavor Diatchki <iavor.diatchki at gmail.com>:
>One tricky bit that occurred to me: we can't really change the behavior
>of
>the Read instance depending on the extensions enabled.
>
>Thus, we would either have to always parse hex floats, even when the
>extension is not on, or never parse them.
>
>I am leaning towards parsing them always, even without the extension. 
>What
>do others think?
>
>-Iavor
>
>
>
>On Tue, Feb 28, 2017 at 5:36 AM, Simon Marlow <marlowsd at gmail.com>
>wrote:
>
>> No objections from me.  Looks useful and not too costly in terms of
>extra
>> complexity.
>>
>> On 27 February 2017 at 21:34, Iavor Diatchki
><iavor.diatchki at gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I was assigned to be the shepherd for the Hex Float proposal  (
>>> https://github.com/ghc-proposals/ghc-proposals/pull/37), so I would
>like
>>> to propose that we accept it for implementation in GHC.
>>>
>>> This is a small change, which can be summarized as follows:
>>>     - allow floating point numbers to be written using hex digits.
>>>
>>> The format is exactly the same as decimal floating point numbers,
>except
>>> for:
>>>     - the literals start with 0x
>>>     - the digits are in hex
>>>     - the exponent symbol is `p` or `P`, instead of `e` or `E`
>>>     - the exponent is in base 2, rather than base 10
>>>
>>> This notation has become popular among people working with floating
>point
>>> numbers, as the numbers you write can be represented exactly, which
>is not
>>> the case for base 10 numbers.
>>>
>>> The following points were discussed:
>>>    - the exact format to use, compared to what's allowed by other
>>> languages: we decided to just follow Haskell's decimal float
>notation, for
>>> least surprise
>>>    - should overflow (which becomes `Inf`) result in a warning?   We
>>> decided that this is an orthogonal issue, also relevant to decimal
>floating
>>> point and made a GHC ticket (#13232)
>>>     - there is an odd interaction between floating point (both
>decimal
>>> and hex) and -XNegativeLiterals, related to negative 0, see ticket
>#13211
>>>      - changing the Read instances for Float and Double to recognize
>hex
>>> floats could break some programs, although that does not seem all
>that
>>> likely
>>>      - there is a question of how many extra pretty printing
>functions to
>>> add to `Numeric`: the current thinking is that maybe just one
>`showHFloat`
>>> is sufficient;  the alternative is to add 5, mirroring the
>>> `show[E,F,G]Float` functions for decimals.
>>>
>>> I also had a stab at implementing the basic notation here:
>>> https://phabricator.haskell.org/D3066
>>> I haven't done the changes to the libraries yet.
>>>
>>> Please let me know if you have any objections or suggestions on what
>>> might needs to be changed.
>>>
>>> Cheers,
>>> -Iavor
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>>
>https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>>
>>


More information about the ghc-steering-committee mailing list