| 2025-02-26 00:00:53 +0100 | <tomsmeding> | hololeap: sepBy ((,) <$> manyTill (char ':') <*> manyTill (lookAhead (oneOf ":," <|> eof))) (char ',') ? |
| 2025-02-26 00:01:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 00:01:26 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-26 00:02:18 +0100 | <hololeap> | hm, you would think with Parsec being a monad, it could be done with: sepBy anyChar (char ',') >>= mapM (...) |
| 2025-02-26 00:02:28 +0100 | <tomsmeding> | anyChar parses _one_ character |
| 2025-02-26 00:02:55 +0100 | <hololeap> | right, s/anyChar/(many anyChar)/ |
| 2025-02-26 00:03:04 +0100 | <tomsmeding> | also, while you can process the result of parsing later using (>>=), parsec always parses _from_ the input string |
| 2025-02-26 00:03:13 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 248 seconds) |
| 2025-02-26 00:03:13 +0100 | ljdarj1 | ljdarj |
| 2025-02-26 00:03:56 +0100 | <tomsmeding> | you can't "re-inject" some arbitrary string into the source to be parsed |
| 2025-02-26 00:04:22 +0100 | <hololeap> | I see |
| 2025-02-26 00:05:03 +0100 | <tomsmeding> | of course you technically can just start a new parser for that string, and you can also `setInput`, but typically both are a bad idea |
| 2025-02-26 00:05:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-26 00:06:24 +0100 | <tomsmeding> | hololeap: also, that "sepBy (many anyChar) (char ',')" wouldn't even work: the `many anyChar` would consume the entire input from here, and because it consumed input, it would count as "succeeded" which means it doesn't backtrack |
| 2025-02-26 00:07:16 +0100 | <tomsmeding> | % import Text.Parsec |
| 2025-02-26 00:07:16 +0100 | <yahb2> | <no output> |
| 2025-02-26 00:07:24 +0100 | <tomsmeding> | % parse (sepBy (many anyChar) (char ',')) "<stdin>" "abc,def,ghi" |
| 2025-02-26 00:07:24 +0100 | <yahb2> | Right ["abc,def,ghi"] |
| 2025-02-26 00:07:41 +0100 | <tomsmeding> | hm, let's see if I can whiteboard code |
| 2025-02-26 00:07:56 +0100 | <tomsmeding> | % parse (sepBy ((,) <$> manyTill (char ':') <*> manyTill (lookAhead (oneOf ":," <|> eof))) (char ',')) "<stdin>" "this:that,black:white" |
| 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:08:07 +0100 | <tomsmeding> | evidently not! |
| 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: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:26 +0100 | <monochrom> | Yikes, abuse of lookAhead again. |
| 2025-02-26 00:08:50 +0100 | <monochrom> | many (satisfy (/= ',')) pretty please |
| 2025-02-26 00:08:59 +0100 | <tomsmeding> | I guess |
| 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:10:09 +0100 | <tomsmeding> | % parse (sepBy ((,) <$> (many (satisfy (/= ':')) <* char ':') <*> many (satisfy (`notElem` ":,"))) (char ',')) "<stdin>" "this:that,black:white" |
| 2025-02-26 00:10:09 +0100 | <yahb2> | Right [("this","that"),("black","white")] |
| 2025-02-26 00:10:20 +0100 | <tomsmeding> | hololeap: there |
| 2025-02-26 00:10:29 +0100 | foul_owl | (~kerry@174-21-138-88.tukw.qwest.net) foul_owl |
| 2025-02-26 00:10:32 +0100 | <hololeap> | cool, thanks :) |
| 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: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: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:11:37 +0100 | <tomsmeding> | if you write out that <$> <*> sequence as a do-block, it gets much more readable |
| 2025-02-26 00:11:39 +0100 | <monochrom> | Oh, the split package has tools for that too. |
| 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:12:40 +0100 | <tomsmeding> | hololeap: https://paste.tomsmeding.com/QHaiHEVF |
| 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:53 +0100 | <tomsmeding> | but yes, a splitting function is perhaps nicer here |
| 2025-02-26 00:16:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 00:20:18 +0100 | rvalue | (~rvalue@user/rvalue) (Quit: ZNC - https://znc.in) |
| 2025-02-26 00:21:03 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-02-26 00:23:46 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-26 00:28:14 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-26 00:32:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 00:36:46 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-02-26 00:37:49 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-02-26 00:38:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-02-26 00:50:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 00:51:13 +0100 | src | (~src@user/src) src |
| 2025-02-26 00:55:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-26 00:58:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 00:59:26 +0100 | <EvanR> | is parsec more or less powerful than regex |
| 2025-02-26 00:59:41 +0100 | <EvanR> | does it hinge on whether unlimited lookahead is regex |
| 2025-02-26 01:00:25 +0100 | <geekosaur> | if regex is extended with "functions", see raku |
| 2025-02-26 01:00:36 +0100 | <mauke> | parsec can nest |
| 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:03:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-02-26 01:07:40 +0100 | <EvanR> | I guess irregular expressions isn't particularly marketable |
| 2025-02-26 01:10:48 +0100 | mange | (~user@user/mange) mange |
| 2025-02-26 01:11:03 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-26 01:12:50 +0100 | <jackdk> | Don't we call those "perl compatible"? |
| 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:14:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 01:14:16 +0100 | <mauke> | backreferences existed long before perl |
| 2025-02-26 01:15:31 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-02-26 01:16:44 +0100 | Googulator78 | (~Googulato@2a01-036d-0106-0c81-ad7c-ac56-196b-c9a2.pool6.digikabel.hu) |
| 2025-02-26 01:16:45 +0100 | <EvanR> | now I have to pull out the history to figure out what "long before perl" means |
| 2025-02-26 01:17:04 +0100 | <geekosaur> | egrep |
| 2025-02-26 01:18:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-26 01:19:42 +0100 | <mauke> | https://unix.stackexchange.com/questions/623521/why-does-ed-support-backreferences-but-not-alterna… |
| 2025-02-26 01:20:10 +0100 | Googulator | (~Googulato@2a01-036d-0106-0c81-ad7c-ac56-196b-c9a2.pool6.digikabel.hu) (Ping timeout: 240 seconds) |
| 2025-02-26 01:21:54 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-02-26 01:26:59 +0100 | <geekosaur> | mm, right, forgot ed went back even further |
| 2025-02-26 01:29:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 01:29:38 +0100 | <ski> | geekosaur : "IrRegular Expressions" by foof at <https://synthcode.com/scheme/irregex/> |
| 2025-02-26 01:32:29 +0100 | krei-se- | (~krei-se@p3ee0f060.dip0.t-ipconnect.de) krei-se |
| 2025-02-26 01:32:35 +0100 | <mauke> | the bell labs regex code wasn't freely available, so perl 2.0 incorporated henry spencer's implementation, which used backtracking |
| 2025-02-26 01:33:36 +0100 | krei-se | (~krei-se@p3ee0fb6e.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-02-26 01:33:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-26 01:34:49 +0100 | ski | . o O ( "Regular Expression Matching Can Be Simple And Fast (but is slow in Java, Perl, PHP, Python, Ruby, ...)" by Russ Cox in 2007-01 at <https://swtch.com/~rsc/regexp/regexp1.html> ) |
| 2025-02-26 01:36:02 +0100 | <mauke> | "With the exception of backreferences, the features provided by the slow backtracking implementations can be provided by the automata-based implementations at dramatically faster, more consistent speeds." is of course wrong |
| 2025-02-26 01:36:26 +0100 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 252 seconds) |
| 2025-02-26 01:40:22 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-02-26 01:44:53 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 01:45:24 +0100 | <geekosaur> | yeh, I think pretty much everyone was using Spencer's code back then |
| 2025-02-26 01:49:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-02-26 01:51:03 +0100 | sprotte24 | (~sprotte24@p200300d16f33ea00547a79769710f53f.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-02-26 01:53:34 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-02-26 01:56:13 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3152:bac6:3fc:3eb6) (Ping timeout: 252 seconds) |
| 2025-02-26 01:56:47 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-26 02:00:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 02:01:00 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-26 02:02:13 +0100 | zungi | (~tory@user/andrewchawk) (Remote host closed the connection) |
| 2025-02-26 02:04:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-26 02:06:47 +0100 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-02-26 02:07:36 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-02-26 02:08:19 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) (Ping timeout: 252 seconds) |
| 2025-02-26 02:15:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 02:16:05 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2025-02-26 02:17:25 +0100 | <cheater> | i'm still dismayed that no one extended regex to include negative matches |
| 2025-02-26 02:17:41 +0100 | <cheater> | since they can always be compiled down to a finite amount of positive matches |
| 2025-02-26 02:18:01 +0100 | <cheater> | just that negative matches are human readable and the positive version isn't |
| 2025-02-26 02:18:37 +0100 | <geekosaur> | actual perl REs have negative matches |
| 2025-02-26 02:18:52 +0100 | <cheater> | as in, "matching this rejects the match"? |
| 2025-02-26 02:18:57 +0100 | <geekosaur> | or at least negative lookahead |
| 2025-02-26 02:19:01 +0100 | <geekosaur> | yes |
| 2025-02-26 02:19:11 +0100 | <cheater> | how would you match for hat, but not within the word what? |
| 2025-02-26 02:19:28 +0100 | yegorc | (~yegorc@user/yegorc) yegorc |
| 2025-02-26 02:19:42 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-02-26 02:19:53 +0100 | <Square> | If I have a project that contains .cabal files it seems newer versions of cabal tries to use all these files to resolve dependencies. Is there a way to neglect other .cabal files in a project? |
| 2025-02-26 02:20:07 +0100 | <Square> | s/contains/contains several/ |
| 2025-02-26 02:20:38 +0100 | <cheater> | idk but maybe cabal.project |
| 2025-02-26 02:20:44 +0100 | <geekosaur> | --ignore-project |
| 2025-02-26 02:21:24 +0100 | <geekosaur> | this isn't usually what you actually want, though, as it can lead to mutually incompatible project components |
| 2025-02-26 02:21:48 +0100 | <geekosaur> | which is why cabal solves for the whole project |
| 2025-02-26 02:22:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-26 02:23:07 +0100 | <Square> | thanks. I'm migrating a project - sub-project by sub-project. |
| 2025-02-26 02:23:32 +0100 | <Square> | ...so during that phase it might help me to work on them individually first |
| 2025-02-26 02:27:01 +0100 | alp | (~alp@2001:861:8ca0:4940:d9b2:488b:3c7b:5f95) (Ping timeout: 252 seconds) |
| 2025-02-26 02:33:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 02:38:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-26 02:42:30 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-26 02:42:55 +0100 | <geekosaur> | you might do better making a temporary project file containing only the parts you need, because eventually you'll hit dependencies within the project and will need them to be visible |
| 2025-02-26 02:43:48 +0100 | yegorc | (~yegorc@user/yegorc) (Leaving) |
| 2025-02-26 02:44:18 +0100 | <Square> | gotcha. I'll keep that in mind if I run into problems |
| 2025-02-26 02:44:25 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-02-26 02:45:23 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Ping timeout: 245 seconds) |
| 2025-02-26 02:47:12 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
| 2025-02-26 02:47:26 +0100 | messewix | (~jmc@user/messewix) messewix |
| 2025-02-26 02:47:57 +0100 | <mauke> | cheater: (?<!w)hat |
| 2025-02-26 02:48:42 +0100 | <cheater> | nice |
| 2025-02-26 02:48:46 +0100 | <cheater> | does this work in any greps? |
| 2025-02-26 02:48:57 +0100 | <mauke> | the positive version is (?:^|[^w])hat |
| 2025-02-26 02:49:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-26 02:49:56 +0100 | <mauke> | should work in GNU grep -P |
| 2025-02-26 02:50:04 +0100 | <mauke> | and ack, if you count that as a grep |
| 2025-02-26 02:50:12 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-02-26 02:53:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |