Make `read` accept binary integer notation

[damhiya]

The BinaryLiterals extension, included in GHC2021, enables binary integer notation (a binary sequence prefixed by 0b or 0B), but the current implementation of read function rejects such input. I propose modifying the read function, along with readEither and readMaybe, to accept binary integer notation in order to maintain consistency with the GHC2021 syntax.

related issue : https://gitlab.haskell.org/ghc/ghc/-/issues/23518
merge request : https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10680

[hasufell]

So you want read to accept this expression: read @Integer "0b11001001".

Right now it seems the workaround is read @Integer . show $ 0b11001001.

What about octal or hexadecimal notation? It seems not accepted either.

[mixphix]

That 0o and 0x prefixes are not supported in the Read instance makes me hesitate. The name of the extension is (excuse the pun) literally BinaryLiterals: it is meant for values made explicit at compile time, written by the programmer. It makes no assumptions about how numbers are to be parsed from other sources.

[damhiya]

So you want read to accept this expression: read @Integer "0b11001001".

Right now it seems the workaround is read @Integer . show $ 0b11001001.

What about octal or hexadecimal notation? It seems not accepted either.

Octal and hexadecimal notations are accepted. Try this:

read "0x10" :: Int

[hasufell]

So you want read to accept this expression: read @Integer "0b11001001".

Right now it seems the workaround is read @Integer . show $ 0b11001001.

What about octal or hexadecimal notation? It seems not accepted either.

Octal and hexadecimal notations are accepted. Try this:

read "0x10" :: Int

You're right. I'm not sure why it didn't work the first time I tried.

In that case it seems an addition that makes things more consistent.

[damhiya]

Maybe you missed type annotation or type application. read "0x10" gives no parse exception in ghci.

[hasufell]

https://play.haskell.org/saved/UsbskHHi

[mixphix]

Wouldn't you know it! Thanks for the demo.

It's unfortunate that binary literals were not supported from the beginning. If we do this and one begins a project without -XBinaryLiterals, they may end up in a situation where read "0b10" succeeds but writing 0b10 in source code errors. Does GHCi use GHC2021 by default these days?

[tomjaguarpaw]

Does GHCi use GHC2021 by default these days?

Yes, since 9.2:

% ghci-9.2
GHCi, version 9.2.4: https://www.haskell.org/ghc/  :? for help
ghci> 0b1
1

[mixphix]

Then it is truly a sad state of affairs that reading binary is unsupported. Please, @damhiya, feel free to open a merge request on which we can vote!

[damhiya]

Here is the fix : https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10680

Is this what do you mean? @mixphix

[mixphix]

Yes, typically the CLC votes on merge requests, not just issues. Thank you!

[damhiya]

https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10680#note_505297
Oleg Grenrus informed me that NumericUnderscores and HexFloatLiterals are also included in GHC2021, and the current implementation of read does not support for these notational extensions.

Here, I am proposing a principle rather than a specific implementation change: to make the Read class consider every language extension related to literal syntax that is included in GHC2021. Following this principle, I suggest adding support for BinaryIntegerLiterals, NumericUnderscores, and HexFloatLiterals to read.

We have to modify definition of Text.Read.Lex.Number type to support 16-base if we accept HexFloatLiterals, but fortunately Text.Read.Lex does not export constructors of Number type so I think there is no problem.

[Bodigrim]

Here, I am proposing a principle rather than a specific implementation change: to make the Read class consider every language extension related to literal syntax that is included in GHC2021. Following this principle, I suggest adding support for BinaryIntegerLiterals, NumericUnderscores, and HexFloatLiterals to read.

Is it possible to actually reuse a parser used by GHC itself? Technically it's more likely to be vice versa: a parser in ghc package can reuse a parser from base. It would be nice to avoid accidental bugs.

[damhiya]

Here, I am proposing a principle rather than a specific implementation change: to make the Read class consider every language extension related to literal syntax that is included in GHC2021. Following this principle, I suggest adding support for BinaryIntegerLiterals, NumericUnderscores, and HexFloatLiterals to read.

Is it possible to actually reuse a parser used by GHC itself? Technically it's more likely to be vice versa: a parser in ghc package can reuse a parser from base. It would be nice to avoid accidental bugs.

I agree that this is ideal, but GHC's lexer is written in alex. I guess it will be hard to integrate them.

[Bodigrim]

@damhiya I like the suggested principle, but I'm somewhat worried about arising complexity and an element of surprise. Current state of GHC.Read is already underspecified. For instance, there is no documented semantics of readNumber at all.

Could you possibly provide a complete MR with improved documentation and added tests?