Newest at the top
| 2024-12-28 08:01:11 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-28 08:00:35 +0100 | JamesMowery439 | (~JamesMowe@ip68-228-212-232.ph.ph.cox.net) JamesMowery |
| 2024-12-28 08:00:19 +0100 | JamesMowery439 | (~JamesMowe@ip68-228-212-232.ph.ph.cox.net) (Quit: Goodbye) |
| 2024-12-28 07:58:32 +0100 | <c_wraith> | just give me simple distributive laws which don't have tons of cases. |
| 2024-12-28 07:57:46 +0100 | <c_wraith> | If I have to know that ((a <*> b) <|> (a <*> c)) is the same as (a <*> (b <|> c)), but ((a <*> c) <|> (b <*> c)) is not the same as ((a <|> b) <*> c), it's gone off the rails. |
| 2024-12-28 07:57:11 +0100 | <haskellbridge> | <maerwald> no idea what that means |
| 2024-12-28 07:56:32 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 07:54:41 +0100 | <c_wraith> | I want basic refactoring to work, which is not what it does. |
| 2024-12-28 07:53:00 +0100 | <haskellbridge> | <maerwald> what you want is non-determinism, that's not what it does |
| 2024-12-28 07:51:40 +0100 | <haskellbridge> | <maerwald> *does |
| 2024-12-28 07:51:27 +0100 | <haskellbridge> | <maerwald> it doesn't backtrack on failure of a single parser |
| 2024-12-28 07:50:05 +0100 | <c_wraith> | being able to parse that string with that parser is backtracking. Not needing to use try to avoid breaking is just not being broken. |
| 2024-12-28 07:48:53 +0100 | <c_wraith> | yeah, attoparsec doesn't backtrack either. parseOnly ((string "a" <|> string "aa") <* string "b") "aab" ----> Left "string" |
| 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 |