Newest at the top
| 2026-02-11 14:10:03 +0100 | juri_ | (~juri@212.86.50.13) (Read error: Connection reset by peer) |
| 2026-02-11 14:09:50 +0100 | juri_ | (~juri@212.86.50.13) juri_ |
| 2026-02-11 14:06:38 +0100 | APic | (apic@apic.name) APic |
| 2026-02-11 14:06:04 +0100 | <gentauro> | ski: got it |
| 2026-02-11 14:05:02 +0100 | omnifunctor | (~omnifunct@user/semifunctor) omnifunctor |
| 2026-02-11 14:04:48 +0100 | omnifunctor | (~omnifunct@user/semifunctor) (Server closed connection) |
| 2026-02-11 14:04:25 +0100 | juri_ | (~juri@212.86.50.13) (Read error: Connection reset by peer) |
| 2026-02-11 14:04:15 +0100 | juri_ | (~juri@212.86.50.13) juri_ |
| 2026-02-11 14:03:29 +0100 | <ski> | well, i said "no [..] `lookAhead'" |
| 2026-02-11 14:02:45 +0100 | <gentauro> | ski: with `lookAhead` you bind your parser logic to a monadic context right? Isn't it better su rely only on (Selective) Applicative and Functors? |
| 2026-02-11 14:01:28 +0100 | APic | (apic@apic.name) (Server closed connection) |
| 2026-02-11 13:58:47 +0100 | juri_ | (~juri@212.86.50.13) (Read error: Connection reset by peer) |
| 2026-02-11 13:58:47 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2026-02-11 13:58:39 +0100 | juri_ | (~juri@212.86.50.13) juri_ |
| 2026-02-11 13:57:26 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 252 seconds) |
| 2026-02-11 13:56:19 +0100 | rensenwxre | fwam |
| 2026-02-11 13:52:57 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-02-11 13:46:45 +0100 | karenw | (~karenw@user/karenw) karenw |
| 2026-02-11 13:44:06 +0100 | driib3180 | (~driib@vmi931078.contaboserver.net) driib |
| 2026-02-11 13:43:28 +0100 | driib3180 | (~driib@vmi931078.contaboserver.net) (Server closed connection) |
| 2026-02-11 13:38:04 +0100 | Beowulf | (florian@2a01:4f9:3b:2d56::2) |
| 2026-02-11 13:37:28 +0100 | Beowulf | (florian@2a01:4f9:3b:2d56::2) (Server closed connection) |
| 2026-02-11 13:35:00 +0100 | fp | (~Thunderbi@wireless-86-50-141-104.open.aalto.fi) (Ping timeout: 252 seconds) |
| 2026-02-11 13:34:33 +0100 | <ski> | (oh, and it should satisfy the right (and left, upto permutation of solutions) distribution law, and also the law that if `p' parses tokens `s' and `q' parses tokens `t', then `p >> q' ought to parse tokens `s <> t' (so, no `eof' nor `lookAhead')) |
| 2026-02-11 13:31:28 +0100 | tremon | (~tremon@83.80.159.219) tremon |
| 2026-02-11 13:30:53 +0100 | fp | (~Thunderbi@wireless-86-50-141-104.open.aalto.fi) fp |
| 2026-02-11 13:29:53 +0100 | ski | would like a mode & determinism tracking system that could be used to ensure that you get the intended efficient switching rather than backtracking, when you expect it, without removing the more general case, nor making it less convenient to express |
| 2026-02-11 13:27:41 +0100 | <tomsmeding> | but I also have to be honest that if you make things more explicit, the whole system doesn't necessarily get nicer -- the rule does somehow strike a balance where a lot of cases can be expressed fairly neatly |
| 2026-02-11 13:26:58 +0100 | <tomsmeding> | I'm not a fan of this model of "backtracking is an error without consuming input", as it's unintuitive and at times inflexible; I prefer my parser combinators more explicit about backtracking and failure |
| 2026-02-11 13:26:05 +0100 | <tomsmeding> | or ("abc" >> eof), if appropriate |
| 2026-02-11 13:25:45 +0100 | <tomsmeding> | ("abc" >> notFollowedBy "d"), for example |
| 2026-02-11 13:25:31 +0100 | <tomsmeding> | The solutions here seem to be swapping the two parsers (in which case the try shouldn't be necessary any more), or augmenting the "abc" parser to explicitly reject a following 'd' |
| 2026-02-11 13:24:44 +0100 | <tomsmeding> | error. |
| 2026-02-11 13:24:42 +0100 | <tomsmeding> | bwe: as people have said, thep roblem is that "abc" succeeds, so the left argument to (<|>) succeeds, so the (<|>) as a whole succeeds and that's that. (Mega)parsec does not do arbitrary backtracking: its model is that if a parser fails while having consumed input, it's an error; if a parser fails without consuming input, we backtrack. 'try' wraps its argument to "undo" the input consumption upon |
| 2026-02-11 13:23:56 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2026-02-11 13:23:25 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 264 seconds) |
| 2026-02-11 13:22:56 +0100 | <ski> | (mm, right. for some reason i was thinking it did the right distributive law, with `try' .. too bad) |
| 2026-02-11 13:18:34 +0100 | prdak1 | prdak |
| 2026-02-11 13:18:34 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 246 seconds) |
| 2026-02-11 13:18:29 +0100 | prdak1 | (~Thunderbi@user/prdak) prdak |
| 2026-02-11 13:14:25 +0100 | trickard_ | trickard |
| 2026-02-11 13:14:09 +0100 | <Leary> | No, it's outside of the `<|>`. |
| 2026-02-11 13:13:21 +0100 | <ski> | (seems to me like the failing end of input ought to trigger backtracking, with the `try' present there, no ?) |
| 2026-02-11 13:06:35 +0100 | <Leary> | `parseTest` seems to be for visual inspection, not automated testing. |
| 2026-02-11 13:05:03 +0100 | <__monty__> | Or use parseTest and just add the type annotation that it complains about. |
| 2026-02-11 13:04:51 +0100 | <Leary> | I think they want the opposite; add `<* takeWhileP (const True)`. |
| 2026-02-11 13:03:51 +0100 | <merijn> | i.e.: parseMaybe (foo <* eof) "stuff here" |
| 2026-02-11 13:03:15 +0100 | <merijn> | bwe: I mean, you could just add "<* eof" to each parse before feeding to parseMaybe? :) |
| 2026-02-11 13:02:36 +0100 | <bwe> | Leary: So this answers why `parseMaybe` behaves differently than when I combine the parser with others. What's then the right function to (unit) test parser combinator segments? |
| 2026-02-11 13:00:15 +0100 | <Leary> | bwe: "This function also parses eof, so if the parser doesn't consume all of its input, it will fail." |