Newest at the top
| 2024-12-28 07:45:21 +0100 | haver | (~Enviosity@2.219.56.221) |
| 2024-12-28 07:43:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-28 07:42:07 +0100 | <c_wraith> | well, sort of. It never discards input it might still choose to use. I don't believe it will actually backtrack on a successful parse if a future parse fails. |
| 2024-12-28 07:42:07 +0100 | <fp> | I know it's not related to backtracking because the misbehaviour is at the beginning of the input |
| 2024-12-28 07:41:21 +0100 | <haskellbridge> | <maerwald> it always backtracks on failure |
| 2024-12-28 07:40:46 +0100 | <haskellbridge> | <maerwald> I prefer attoparsec |
| 2024-12-28 07:40:44 +0100 | <c_wraith> | not using it when you need to will make parses fail for no apparent reason. |
| 2024-12-28 07:40:13 +0100 | <c_wraith> | If you're using megaparsec, you need to know when/why to use try |
| 2024-12-28 07:39:36 +0100 | <fp> | (unrelated to my question) |
| 2024-12-28 07:39:31 +0100 | <haskellbridge> | <maerwald> that would then use the function applicative instance I believe |
| 2024-12-28 07:39:30 +0100 | <fp> | now to figure out why that didn't solve my problem |
| 2024-12-28 07:39:19 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 07:39:16 +0100 | <fp> | right yeah, that was it |
| 2024-12-28 07:38:21 +0100 | <haskellbridge> | <maerwald> without parens, you have (optional string) "#d" |
| 2024-12-28 07:37:54 +0100 | <c_wraith> | I should stop trying to type correctly tonight. option*al*. |
| 2024-12-28 07:37:38 +0100 | <c_wraith> | option (string "#d") |
| 2024-12-28 07:37:31 +0100 | <c_wraith> | oh, right. |
| 2024-12-28 07:37:23 +0100 | <haskellbridge> | <maerwald> missing parenthesis too I think |
| 2024-12-28 07:37:19 +0100 | <fp> | same that way |
| 2024-12-28 07:37:10 +0100 | <c_wraith> | yeah, flip that to *> |
| 2024-12-28 07:36:57 +0100 | <fp> | number <- optional string "#d" <* someTill decimalDigit (lookAhead delimiter) |
| 2024-12-28 07:36:41 +0100 | <haskellbridge> | <maerwald> show the real code |
| 2024-12-28 07:36:36 +0100 | <c_wraith> | What are you doing to make it not? |
| 2024-12-28 07:36:27 +0100 | <c_wraith> | optional returns a parser. |
| 2024-12-28 07:36:26 +0100 | <haskellbridge> | <maerwald> yes |
| 2024-12-28 07:36:12 +0100 | <fp> | looking at the type signature of (*>), I think both sides need to be of the same monad? |
| 2024-12-28 07:35:46 +0100 | <fp> | That still gives me a type error on the left side that it's Maybe and not Parser |
| 2024-12-28 07:35:17 +0100 | <haskellbridge> | <maerwald> The effect of a parser is consuming input or failing... a maybe parser never fails (but may backtrack, depending on how you defined it). You only care about the effect here, but not the value (Maybe). That's what (*>) does. |
| 2024-12-28 07:32:07 +0100 | <c_wraith> | err. *> |
| 2024-12-28 07:31:53 +0100 | <c_wraith> | optional (chunk "#d") <* some (satisfy isDigit) |
| 2024-12-28 07:30:35 +0100 | <fp> | or is that what you're saying? |
| 2024-12-28 07:29:53 +0100 | <fp> | So I don't want for decimalParser to be Maybe, like the grammar I want is like <decimal> ::= "#d"? [0-9]+, so I just want something like the ? |
| 2024-12-28 07:28:02 +0100 | <haskellbridge> | <maerwald> the effect of a parser is that it consumes input (or not) |
| 2024-12-28 07:27:22 +0100 | <c_wraith> | In particular, both (*>) and (<*) do just "throw away" things in exactly the way you'd want. (You use *> more standalone, <* more in applicative chains) |
| 2024-12-28 07:27:14 +0100 | <haskellbridge> | <maerwald> you run both effects, but discard the left value |
| 2024-12-28 07:27:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 07:27:01 +0100 | <haskellbridge> | <maerwald> (*>) :: f a -> f b -> f b |
| 2024-12-28 07:26:24 +0100 | <haskellbridge> | <maerwald> :t (*>) |
| 2024-12-28 07:25:30 +0100 | <haskellbridge> | <maerwald> maybeParser *> decimalParser |
| 2024-12-28 07:23:48 +0100 | <fp> | How, with megaparsec, does one represent an optional parser? The problem I'm solving is that I have a decimal literal, which can be like =1234= or =#d1234=, so the =#d= is optional and I don't care about the value. =optional= exists, but it creates a =Maybe= which I can't just throw away its value |
| 2024-12-28 07:22:43 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-28 07:22:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 07:18:22 +0100 | notzmv | (~umar@user/notzmv) (Ping timeout: 265 seconds) |
| 2024-12-28 07:18:19 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-12-28 07:08:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-28 07:03:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 06:58:04 +0100 | tnt2 | tnt1 |
| 2024-12-28 06:58:04 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 265 seconds) |
| 2024-12-28 06:56:26 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2024-12-28 06:53:26 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |