Proposal: add ReadPrec-based functions to Read1/Read2

GHC 8.0 added the Data.Functor.Classes module [1] to base, and with it the Read1 and Read2 typeclasses. The current definition of Read1 is this: class Read1 f where liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a) liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a] There's a pretty big problem with this definition: it uses ReadS (a synonym for String -> [(a, String)]). This sort of parser is very slow (the docs even admit as such [2]), and moreover, the actual Read typeclass on which Read1 is based tries to avoid using it whenever possible. The Read typeclass has this definition currently: class Read a where readsPrec :: Int -> ReadS a readList :: ReadS [a] readPrec :: ReadPrec a readListPrec :: ReadPrec [a] Where ReadPrec is a much more efficient parser datatype. When deriving Read instances, GHC defines them in terms of readPrec, and gives the other methods default definitions that leverage readPrec. For the sake of consistency, I propose adding analogous methods to Read1 and Read2 that use the ReadPrec datatype. For example, here is how I would change Read1: class Read1 f where liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a) liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a] liftReadPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec (f a) liftReadListPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec [f a] And similarly for Read2. Here is a full gist [3] with a sketch of what the new Read1/Read2 definitions would look like, including what the default definitions of the other methods would be. Ryan S. ----- [1] http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Functor-Classes.ht... [2] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-ParserCombinators-... [3] https://gist.github.com/RyanGlScott/7cdd11d6aa878e4229acf1a682beb1fc

I'm always in favor of providing algorithmicly better interfaces, so
barring me learning that there's doe thing even better we should do , +1 :)
On Sunday, June 19, 2016, Ryan Scott
GHC 8.0 added the Data.Functor.Classes module [1] to base, and with it the Read1 and Read2 typeclasses. The current definition of Read1 is this:
class Read1 f where liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a) liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a]
There's a pretty big problem with this definition: it uses ReadS (a synonym for String -> [(a, String)]). This sort of parser is very slow (the docs even admit as such [2]), and moreover, the actual Read typeclass on which Read1 is based tries to avoid using it whenever possible.
The Read typeclass has this definition currently:
class Read a where readsPrec :: Int -> ReadS a readList :: ReadS [a] readPrec :: ReadPrec a readListPrec :: ReadPrec [a]
Where ReadPrec is a much more efficient parser datatype. When deriving Read instances, GHC defines them in terms of readPrec, and gives the other methods default definitions that leverage readPrec.
For the sake of consistency, I propose adding analogous methods to Read1 and Read2 that use the ReadPrec datatype. For example, here is how I would change Read1:
class Read1 f where liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a) liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a] liftReadPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec (f a) liftReadListPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec [f a]
And similarly for Read2. Here is a full gist [3] with a sketch of what the new Read1/Read2 definitions would look like, including what the default definitions of the other methods would be.
Ryan S. ----- [1] http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Functor-Classes.ht... [2] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-ParserCombinators-... [3] https://gist.github.com/RyanGlScott/7cdd11d6aa878e4229acf1a682beb1fc _______________________________________________ Libraries mailing list Libraries@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

I suppose I should eventually step and start voting on proposals instead of
just observing the process... so +1 as well.
On Mon, Jun 20, 2016 at 4:29 PM, wren romano
On Sun, Jun 19, 2016 at 6:56 PM, Carter Schonwald
wrote: I'm always in favor of providing algorithmicly better interfaces, so barring me learning that there's doe thing even better we should do , +1 :)
+1.
-- Live well, ~wren _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
participants (4)
-
Carter Schonwald
-
Ryan Scott
-
Theodore Lief Gannon
-
wren romano