Newest at the top
| 2024-12-28 08:52:18 +0100 | Flow | (~none@gentoo/developer/flow) flow |
| 2024-12-28 08:51:31 +0100 | Digit | (~user@user/digit) Digit |
| 2024-12-28 08:50:12 +0100 | Digitteknohippie | (~user@user/digit) (Ping timeout: 265 seconds) |
| 2024-12-28 08:49:10 +0100 | Flow | (~none@gentoo/developer/flow) (Ping timeout: 252 seconds) |
| 2024-12-28 08:48:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-28 08:47:26 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) |
| 2024-12-28 08:46:15 +0100 | Digit | (~user@user/digit) (Ping timeout: 244 seconds) |
| 2024-12-28 08:45:39 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2024-12-28 08:44:19 +0100 | Milan | (~Milan@88.212.61.169) (Remote host closed the connection) |
| 2024-12-28 08:44:01 +0100 | Milan | (~Milan@88.212.61.169) |
| 2024-12-28 08:43:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 08:32:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-28 08:27:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 08:25:37 +0100 | ephilalethes | (~noumenon@202.186.200.33) (Read error: Connection reset by peer) |
| 2024-12-28 08:24:39 +0100 | housemate | (~housemate@pa49-199-79-186.pa.vic.optusnet.com.au) (Ping timeout: 252 seconds) |
| 2024-12-28 08:21:48 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 264 seconds) |
| 2024-12-28 08:18:42 +0100 | euleritian | (~euleritia@dynamic-176-006-141-001.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-12-28 08:14:02 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-12-28 08:08:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-28 08:07:32 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2024-12-28 08:06:55 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2024-12-28 08:02:12 +0100 | <c_wraith> | But they do hold for the parser combinator library in base! |
| 2024-12-28 08:01:23 +0100 | housemate | (~housemate@pa49-199-79-186.pa.vic.optusnet.com.au) housemate |
| 2024-12-28 08:01:18 +0100 | <haskellbridge> | <maerwald> well, distributive laws don't hold for Alternative even in core libs |
| 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 |