Newest at the top
| 2025-02-26 01:15:31 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-02-26 01:14:16 +0100 | <mauke> | backreferences existed long before perl |
| 2025-02-26 01:14:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 01:13:47 +0100 | <mauke> | I think "perl compatible" is mostly about syntax (ok, and some features as well) |
| 2025-02-26 01:12:50 +0100 | <jackdk> | Don't we call those "perl compatible"? |
| 2025-02-26 01:11:03 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-26 01:10:48 +0100 | mange | (~user@user/mange) mange |
| 2025-02-26 01:07:40 +0100 | <EvanR> | I guess irregular expressions isn't particularly marketable |
| 2025-02-26 01:03:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-02-26 01:00:57 +0100 | <geekosaur> | but there's some question as to whether that's actually "regex" (I think the "actually should be regular " ship sailed years ago) |
| 2025-02-26 01:00:36 +0100 | <mauke> | parsec can nest |
| 2025-02-26 01:00:25 +0100 | <geekosaur> | if regex is extended with "functions", see raku |
| 2025-02-26 00:59:41 +0100 | <EvanR> | does it hinge on whether unlimited lookahead is regex |
| 2025-02-26 00:59:26 +0100 | <EvanR> | is parsec more or less powerful than regex |
| 2025-02-26 00:58:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 00:55:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-26 00:51:13 +0100 | src | (~src@user/src) src |
| 2025-02-26 00:50:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 00:38:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-02-26 00:37:49 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-02-26 00:36:46 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-02-26 00:32:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 00:28:14 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-26 00:23:46 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-26 00:21:03 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-02-26 00:20:18 +0100 | rvalue | (~rvalue@user/rvalue) (Quit: ZNC - https://znc.in) |
| 2025-02-26 00:16:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 00:12:53 +0100 | <tomsmeding> | but yes, a splitting function is perhaps nicer here |
| 2025-02-26 00:12:43 +0100 | <monochrom> | Although, I confess that I want 0 dependencies so I wrote my own recursion :) |
| 2025-02-26 00:12:40 +0100 | <tomsmeding> | hololeap: https://paste.tomsmeding.com/QHaiHEVF |
| 2025-02-26 00:12:12 +0100 | <monochrom> | You can write your own recursion over span. But the split package does that for you. |
| 2025-02-26 00:11:39 +0100 | <monochrom> | Oh, the split package has tools for that too. |
| 2025-02-26 00:11:37 +0100 | <tomsmeding> | if you write out that <$> <*> sequence as a do-block, it gets much more readable |
| 2025-02-26 00:10:57 +0100 | <hololeap> | although I wonder if it would be more readable to just do this with span from Data.List |
| 2025-02-26 00:10:44 +0100 | <monochrom> | BTW the "convenience" of regex allowing that is avenged by the fact that such high non-determinism causes exp-time or exp-space. |
| 2025-02-26 00:10:43 +0100 | <tomsmeding> | monochrom: thanks, it's been too long since I parsec'd, this is also nicer to write |
| 2025-02-26 00:10:32 +0100 | <hololeap> | cool, thanks :) |
| 2025-02-26 00:10:29 +0100 | foul_owl | (~kerry@174-21-138-88.tukw.qwest.net) foul_owl |
| 2025-02-26 00:10:20 +0100 | <tomsmeding> | hololeap: there |
| 2025-02-26 00:10:09 +0100 | <yahb2> | Right [("this","that"),("black","white")] |
| 2025-02-26 00:10:09 +0100 | <tomsmeding> | % parse (sepBy ((,) <$> (many (satisfy (/= ':')) <* char ':') <*> many (satisfy (`notElem` ":,"))) (char ',')) "<stdin>" "this:that,black:white" |
| 2025-02-26 00:09:49 +0100 | <monochrom> | What you should really lament, if you like, is that parsec is not regex, so whereas in regex you just have to say ".*,.*", you simply can't do that in parsec. |
| 2025-02-26 00:08:59 +0100 | <tomsmeding> | I guess |
| 2025-02-26 00:08:50 +0100 | <monochrom> | many (satisfy (/= ',')) pretty please |
| 2025-02-26 00:08:26 +0100 | <monochrom> | Yikes, abuse of lookAhead again. |
| 2025-02-26 00:08:23 +0100 | <yahb2> | <interactive>:289:99: error: [GHC-83865] ; • Couldn't match type ‘()’ with ‘Char’ ; Expected: ParsecT ; String () GHC.Internal.Data.Functor.Identity.Identity Char ; ... |
| 2025-02-26 00:08:23 +0100 | <tomsmeding> | % parse (sepBy ((,) <$> manyTill anyChar (char ':') <*> manyTill anyChar (lookAhead (oneOf ":," <|> eof))) (char ',')) "<stdin>" "this:that,black:white" |
| 2025-02-26 00:08:07 +0100 | <tomsmeding> | evidently not! |
| 2025-02-26 00:07:56 +0100 | <yahb2> | <interactive>:287:23: error: [GHC-83865] ; • Couldn't match expected type: ParsecT ; String () GHC.Internal.Data.Functor.Identity.Identity a1 ; ... |
| 2025-02-26 00:07:56 +0100 | <tomsmeding> | % parse (sepBy ((,) <$> manyTill (char ':') <*> manyTill (lookAhead (oneOf ":," <|> eof))) (char ',')) "<stdin>" "this:that,black:white" |