Newest at the top
| 2025-05-02 20:18:20 +0200 | <dminuoso> | cutting :: ParserT st e a -> e -> (e -> e -> e) -> ParserT st e a |
| 2025-05-02 20:18:14 +0200 | <dminuoso> | So one of the most common primitives you end up using is |
| 2025-05-02 20:17:32 +0200 | __jmcantrell__ | (~weechat@user/jmcantrell) jmcantrell |
| 2025-05-02 20:17:10 +0200 | <dminuoso> | The idea is that failure represent exceptions, and `error` represents some "backtrack" path in the parser tree. |
| 2025-05-02 20:16:34 +0200 | <dminuoso> | (And some machinery to convert between one and another) |
| 2025-05-02 20:16:23 +0200 | <dminuoso> | EvanR: unrecoverable failure and recoverable errors. |
| 2025-05-02 20:15:29 +0200 | <EvanR> | nom-style? |
| 2025-05-02 20:14:54 +0200 | <dminuoso> | attoparsec cant, and with megaparsec its very painful. |
| 2025-05-02 20:14:38 +0200 | <dminuoso> | Also whats really nice about flatparse is that you can interleave it with IO or ST |
| 2025-05-02 20:14:12 +0200 | <haskellbridge> | <Morj> Ah mince |
| 2025-05-02 20:13:41 +0200 | <dminuoso> | The one thing it cant do out of th ebox easily is streaming, however. |
| 2025-05-02 20:13:26 +0200 | <dminuoso> | Personally I would recommend flatparse over megaparsec or attoparsec both because it has nom-style error/failure disambiguation, and internally it is simple and has very customizable errors this way |
| 2025-05-02 20:13:23 +0200 | <haskellbridge> | <Morj> Huh, never heard about flatparse, looks cool with the speed. I already try to write non-backtracking attoparsec, so should be a good replacement |
| 2025-05-02 20:13:15 +0200 | <haskellbridge> | <Liamzee> you can model a database as a transaction |
| 2025-05-02 20:11:56 +0200 | <EvanR> | transaction != immutable database |
| 2025-05-02 20:11:51 +0200 | <dminuoso> | flatparse comes with unicode combinators, so you can consume say UTF8 encoded strings easily too |
| 2025-05-02 20:11:34 +0200 | <dminuoso> | Note that being "bytestring specialized" is not as restrictive as it might sound. |
| 2025-05-02 20:11:31 +0200 | <haskellbridge> | <Liamzee> EvanR: Transaction a in the hasql ecosystem is a thing |
| 2025-05-02 20:11:14 +0200 | <monochrom> | Completely sidesteps all the desire for lock-free data structures. Who needs those? |
| 2025-05-02 20:11:08 +0200 | <dminuoso> | 18:04:52 +haskellbridge │ <Liamzee> but it's bytestring specialized |
| 2025-05-02 20:10:42 +0200 | <monochrom> | Even when I have two concurrent threads accessing the same BST, I have an immutable BST, the sharing is done by an IORef and atomicModifyIORef. |
| 2025-05-02 20:10:14 +0200 | <EvanR> | pass whole databases around |
| 2025-05-02 20:10:02 +0200 | <EvanR> | why stop there, make the database immutable by default |
| 2025-05-02 20:09:35 +0200 | <monochrom> | I have immutable objects by default. |
| 2025-05-02 20:09:34 +0200 | <EvanR> | supposedly you can change the token type in megaparsec so it's not just text |
| 2025-05-02 20:09:28 +0200 | <haskellbridge> | <Liamzee> maybe this? https://hackage.haskell.org/package/const |
| 2025-05-02 20:08:47 +0200 | <haskellbridge> | <Liamzee> IORef except read-only, no exposed constructors, interface only allows you to set an object |
| 2025-05-02 20:08:30 +0200 | <haskellbridge> | <Liamzee> i mean, i feel like screw this, even though it's not a solution, but ConstRef |
| 2025-05-02 20:08:17 +0200 | <monochrom> | And if you say "try" but it is some "try p" where p just consumes O(1) characters, you effectively stay within LL(k). |
| 2025-05-02 20:07:43 +0200 | <haskellbridge> | <Liamzee> even Haskell's records are (spiritually) mutable |
| 2025-05-02 20:07:34 +0200 | <haskellbridge> | <Liamzee> i'm just curious, though, why don't you have non-mutable objects by default? |
| 2025-05-02 20:07:03 +0200 | <monochrom> | So for example even in parsec if you don't say "try" it doesn't backtrack. |
| 2025-05-02 20:06:23 +0200 | <monochrom> | Most don't backtrack unless you tell it to. ReadP does BFS altogether so it "doesn't" backtrack but it sidetracks. |
| 2025-05-02 20:05:55 +0200 | <haskellbridge> | <Liamzee> but faster than nom!!111 |
| 2025-05-02 20:05:51 +0200 | <haskellbridge> | <Liamzee> also, you can read about the downsides in the readme |
| 2025-05-02 20:05:16 +0200 | <haskellbridge> | <Liamzee> someone ghosted me once for saying attoparsec can be treated as a default when they responded megaparsec is text parser, attoparsec is a bytestring parser |
| 2025-05-02 20:05:11 +0200 | <yin> | that's not a bad thing :) |
| 2025-05-02 20:04:52 +0200 | <haskellbridge> | <Liamzee> but it's bytestring specialized |
| 2025-05-02 20:04:48 +0200 | <haskellbridge> | <Liamzee> oh, it backtracks |
| 2025-05-02 20:04:28 +0200 | <yin> | Liamzee: ty |
| 2025-05-02 20:04:28 +0200 | <haskellbridge> | <Liamzee> I don't think flatparse backtracks? Not sure about it. |
| 2025-05-02 20:04:15 +0200 | <monochrom> | But if you don't have a choice yet and don't mind following popularity, megaparsec is more popular generally, attoparsec is more popular for those who want speed, and parsec or ReadP is more popular among the minority of us who just want what comes with GHC. |
| 2025-05-02 20:03:53 +0200 | <yin> | that's what i'm trying to learn |
| 2025-05-02 20:03:26 +0200 | <yin> | monochrom: that's the problem. i don't know what the options are |
| 2025-05-02 20:03:08 +0200 | <haskellbridge> | <Liamzee> https://gist.github.com/chrisdone/8551675bb99a0d66cf075fdcb1e6b757 |
| 2025-05-02 20:03:02 +0200 | <yin> | what's the most performant library and what are its main downsides? |
| 2025-05-02 20:02:50 +0200 | <haskellbridge> | <Liamzee> https://hackage.haskell.org/package/flatparse-0.5.2.1 |
| 2025-05-02 20:02:47 +0200 | <haskellbridge> | <Liamzee> i'm confusing it with optparse-applicative |
| 2025-05-02 20:02:44 +0200 | <monochrom> | Then start with what you will finally use. :) |
| 2025-05-02 20:02:25 +0200 | <haskellbridge> | <Liamzee> erm, flatparse |