Dear Cafe, I could use a parser that is equivalent to the one produced by "deriving Read" but ... A) faster, and using less space (Data.Text(.Lazy) instead of String) B) streaming (parse a long list literal "[0,1,2, ... ]" in constant space, produce the first cons of the result right after reading "[0") C) with some minimal error reporting (e.g., some prefix of not-consumed input) perhaps attoparsec with some form of early-commited choice? I do have something (only for A) at https://codeberg.org/jwaldmann/text-read (attoparsec on lazy text) and it seems twice as fast as "deriving Read" in my tests. NB: I was quite shocked to see that "deriving Read" accepts "Just Foo { foo = 42 }" (no parentheses around the record literal) (while "deriving Show" produces them). - J.W.
Just Foo { foo = 42 } is valid Haskell syntax. I actually take advantage of this in patterns sometimes, although it can definitely be a bit confusing. (And in expressions, I 100% would have extra parentheses, otherwise it's too visually confusing.) On Tue, Aug 18, 2026 at 7:45 AM Johannes Waldmann via Haskell-Cafe < haskell-cafe@haskell.org> wrote:
Dear Cafe,
I could use a parser that is equivalent to the one produced by "deriving Read" but ...
A) faster, and using less space (Data.Text(.Lazy) instead of String) B) streaming (parse a long list literal "[0,1,2, ... ]" in constant space, produce the first cons of the result right after reading "[0") C) with some minimal error reporting (e.g., some prefix of not-consumed input)
perhaps attoparsec with some form of early-commited choice?
I do have something (only for A) at https://codeberg.org/jwaldmann/text-read (attoparsec on lazy text) and it seems twice as fast as "deriving Read" in my tests.
NB: I was quite shocked to see that "deriving Read" accepts "Just Foo { foo = 42 }" (no parentheses around the record literal) (while "deriving Show" produces them).
- J.W.
_______________________________________________ Haskell-Cafe mailing list -- haskell-cafe@haskell.org To (un)subscribe, modify options or view archives go to: Only members subscribed via the mailman list are allowed to post.
To highlight the point about expressions, I've found many beginners are surprised by the behavior of code like this: ghci> data Foo = Foo { foo :: Int } ghci> bar (Foo n) = n + 5 ghci> bar Foo { foo = 9 } 14 To point out a case where this can lead to real bugs, imagine: ghci> data State = State { new :: String, old :: String } deriving (Show) ghci> backup s = s { old = new s } ghci> backup (State "v1" "v0") { new = "v2" } State {new = "v2", old = "v2"} Many might expect this to return (State "v2" "v1"), thinking function application would have higher precedence than the record update. - Tom
On 08/18/2026 4:49 PM CEST Tikhon Jelvis <tikhon@jelv.is> wrote:
Just Foo { foo = 42 } is valid Haskell syntax. I actually take advantage of this in patterns sometimes, although it can definitely be a bit confusing. (And in expressions, I 100% would have extra parentheses, otherwise it's too visually confusing.)
On Tue, Aug 18, 2026 at 7:45 AM Johannes Waldmann via Haskell-Cafe <haskell-cafe@haskell.org> wrote:
Dear Cafe,
I could use a parser that is equivalent to the one produced by "deriving Read" but ...
A) faster, and using less space (Data.Text(.Lazy) instead of String) B) streaming (parse a long list literal "[0,1,2, ... ]" in constant space, produce the first cons of the result right after reading "[0") C) with some minimal error reporting (e.g., some prefix of not-consumed input)
perhaps attoparsec with some form of early-commited choice?
I do have something (only for A) at https://codeberg.org/jwaldmann/text-read (attoparsec on lazy text) and it seems twice as fast as "deriving Read" in my tests.
NB: I was quite shocked to see that "deriving Read" accepts "Just Foo { foo = 42 }" (no parentheses around the record literal) (while "deriving Show" produces them).
- J.W.
_______________________________________________ Haskell-Cafe mailing list -- haskell-cafe@haskell.org To (un)subscribe, modify options or view archives go to: Only members subscribed via the mailman list are allowed to post.
Haskell-Cafe mailing list -- haskell-cafe@haskell.org To (un)subscribe, modify options or view archives go to: Only members subscribed via the mailman list are allowed to post.
I agree. It's confusing. I tend to surround records in parentheses just to make my intention clear, even when it's not needed. Ivan On Sat, 22 Aug 2026 at 18:29, amindfv--- via Haskell-Cafe < haskell-cafe@haskell.org> wrote:
To highlight the point about expressions, I've found many beginners are surprised by the behavior of code like this:
ghci> data Foo = Foo { foo :: Int } ghci> bar (Foo n) = n + 5 ghci> bar Foo { foo = 9 } 14
To point out a case where this can lead to real bugs, imagine:
ghci> data State = State { new :: String, old :: String } deriving (Show) ghci> backup s = s { old = new s } ghci> backup (State "v1" "v0") { new = "v2" } State {new = "v2", old = "v2"}
Many might expect this to return (State "v2" "v1"), thinking function application would have higher precedence than the record update.
- Tom
On 08/18/2026 4:49 PM CEST Tikhon Jelvis <tikhon@jelv.is> wrote:
Just Foo { foo = 42 } is valid Haskell syntax. I actually take advantage of this in patterns sometimes, although it can definitely be a bit confusing. (And in expressions, I 100% would have extra parentheses, otherwise it's too visually confusing.)
On Tue, Aug 18, 2026 at 7:45 AM Johannes Waldmann via Haskell-Cafe < haskell-cafe@haskell.org> wrote:
Dear Cafe,
I could use a parser that is equivalent to the one produced by "deriving Read" but ...
A) faster, and using less space (Data.Text(.Lazy) instead of String) B) streaming (parse a long list literal "[0,1,2, ... ]" in constant space, produce the first cons of the result right after reading "[0") C) with some minimal error reporting (e.g., some prefix of not-consumed input)
perhaps attoparsec with some form of early-commited choice?
I do have something (only for A) at https://codeberg.org/jwaldmann/text-read (attoparsec on lazy text) and it seems twice as fast as "deriving Read" in my tests.
NB: I was quite shocked to see that "deriving Read" accepts "Just Foo { foo = 42 }" (no parentheses around the record literal) (while "deriving Show" produces them).
- J.W.
_______________________________________________ Haskell-Cafe mailing list -- haskell-cafe@haskell.org To (un)subscribe, modify options or view archives go to: Only members subscribed via the mailman list are allowed to post.
Haskell-Cafe mailing list -- haskell-cafe@haskell.org To (un)subscribe, modify options or view archives go to: Only members subscribed via the mailman list are allowed to post.
Haskell-Cafe mailing list -- haskell-cafe@haskell.org To (un)subscribe, modify options or view archives go to: Only members subscribed via the mailman list are allowed to post.
participants (4)
-
amindfv＠mailbox.org -
Ivan Perez -
Johannes Waldmann -
Tikhon Jelvis