Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 235 236 237 238 239 240 241 242 243 244 245 .. 5022
— 502,152 events total
2020-09-26 20:11:13 <dsal> yeah
2020-09-26 20:11:22 × takuan quits (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2020-09-26 20:11:24 <Cale> Which function?
2020-09-26 20:11:27 × geekosaur quits (42d52102@66.213.33.2) (Remote host closed the connection)
2020-09-26 20:11:27 × adam_wespiser quits (~adam_wesp@209.6.42.110) (Ping timeout: 240 seconds)
2020-09-26 20:11:33 <fluturel> at this point, i don't think i want to
2020-09-26 20:12:26 <fluturel> Cale: sum' :: (Num a, Num b) => [a] -> b
2020-09-26 20:13:16 <Cale> Not which doesn't ignore the elements of the input list...
2020-09-26 20:13:20 <Uniaika> *
2020-09-26 20:13:32 <Uniaika> evening
2020-09-26 20:13:44 → dhil joins (~dhil@11.29.39.217.dyn.plus.net)
2020-09-26 20:14:21 <pie_> in haskell combinator libraries does something like "many eof" hang? because it does hand in python's parsy library and i want to know if i should file a bug report of if thats reasonable behavior
2020-09-26 20:14:26 <Cale> With Integral a, you could convert them to Integer and then to b from there
2020-09-26 20:14:31 <dsal> Right. You'd need more constraints to do something slightly useful, which is converting from whatever type to another type, but doing that conversion where you need it would make everything easier.
2020-09-26 20:14:37 <pie_> the eof parser just checks if the "index" in the "stream" is >= the length...
2020-09-26 20:15:35 <monochrom> int-e: In that case, I took a Bernard Shaw quote and brought it to a new level: "I argue with myself all the time, it adds sparks to my debates."
2020-09-26 20:16:30 <monochrom> But really, we know what "put on your user hat" and "put on your implementer hat" mean, and how to do it.
2020-09-26 20:16:31 <Cale> pie_: It probably depends on the library, but at least ReadP manages to parse (many eof) successfully on an empty input.
2020-09-26 20:16:45 → dsf_ joins (~dsf@2605:e000:1c0b:47c2:6014:cd97:238c:74bb)
2020-09-26 20:17:21 → o1lo01ol1o joins (~o1lo01ol1@bl8-213-81.dsl.telepac.pt)
2020-09-26 20:17:40 × merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds)
2020-09-26 20:17:54 × _vaibhavingale_ quits (~Adium@203.188.228.27) (Quit: Leaving.)
2020-09-26 20:17:55 <Cale> (and on a nonempty input)
2020-09-26 20:18:16 → _vaibhavingale_ joins (~Adium@203.188.228.27)
2020-09-26 20:18:16 × _vaibhavingale_ quits (~Adium@203.188.228.27) (Client Quit)
2020-09-26 20:18:26 × directhex1 quits (~directhex@195.206.169.184) (Remote host closed the connection)
2020-09-26 20:18:28 × dsf quits (~dsf@cpe-75-82-64-167.socal.res.rr.com) (Ping timeout: 246 seconds)
2020-09-26 20:18:33 → _vaibhavingale_ joins (~Adium@203.188.228.27)
2020-09-26 20:19:01 × _vaibhavingale_ quits (~Adium@203.188.228.27) (Client Quit)
2020-09-26 20:19:46 <pie_> Cale: my actual problem is that it hangs
2020-09-26 20:20:01 <pie_> what it looks like in python: eof.many().parse("") jhangs
2020-09-26 20:20:41 <Cale> Applying many to a parser which accepts an empty string is usually going to be dangerous
2020-09-26 20:20:42 <pie_> and im not sure what to do about it because im trying to do something like any_line.many(), where a variant is line can be an empty at the end of the file...
2020-09-26 20:20:44 <pie_> hm
2020-09-26 20:20:52 <pie_> Cale: yeah
2020-09-26 20:21:33 <pie_> so what i actually have is any_line = (not eof or newline).many() << (eof | newline)
2020-09-26 20:21:43 <pie_> and i run into the problem when i do any_line.many()
2020-09-26 20:21:53 <pie_> and idk how to restructure it
2020-09-26 20:21:55 × Kaeipi quits (~Kaiepi@47.55.157.9) (Remote host closed the connection)
2020-09-26 20:21:57 <pie_> so that it works
2020-09-26 20:22:14 × o1lo01ol1o quits (~o1lo01ol1@bl8-213-81.dsl.telepac.pt) (Ping timeout: 256 seconds)
2020-09-26 20:23:09 <pie_> oh hm maybe i should just (text << (newline | eof)) | (empty line << newline)
2020-09-26 20:25:09 <pie_> (pseudocode)
2020-09-26 20:26:02 × m4lvin quits (~m4lvin@w4eg.de) (Quit: m4lvin)
2020-09-26 20:26:03 <Turmfalke> pie_: In parsec you could use something like `manyTill (newline <|> eof)`
2020-09-26 20:26:22 → m4lvin joins (~m4lvin@w4eg.de)
2020-09-26 20:26:35 <Turmfalke> `manyTill anyChar (newline <|> eof)` actually
2020-09-26 20:26:52 <Cale> Turmfalke: Well, but could you apply many to *that*?
2020-09-26 20:26:58 <monochrom> This feels like a wild goose chase because first of all there is no reason to believe that python's parsy has remotely the same semantics as parsec or megaparsec.
2020-09-26 20:27:19 <monochrom> (in particular how much backtracking happens)
2020-09-26 20:27:27 <Turmfalke> Cale: Why not?
2020-09-26 20:27:51 <Turmfalke> Hhm, ah...
2020-09-26 20:27:51 → Guest_2 joins (59401d45@89-64-29-69.dynamic.chello.pl)
2020-09-26 20:28:05 <Cale> eof accepts on empty input, and many doesn't like parsers which accept on empty input
2020-09-26 20:28:29 → |Kin| joins (~|Kin|@178.162.212.214)
2020-09-26 20:29:12 <pie_> cool i think it works, thanks for rubbr ducking :D
2020-09-26 20:29:58 <pie_> monochrom: i dunno id assume most monadic parser combinators behave at least somewhat similar?
2020-09-26 20:30:37 <Cale> They're *somewhat* similar, but there are differences when you get to subtle issues like this one
2020-09-26 20:30:55 <pie_> hm
2020-09-26 20:31:26 <pie_> it doenst help that i dont really understand how it works
2020-09-26 20:31:32 <Cale> (The one I tried first is completely okay with parsing many eof, even though the list of parses it gives you is infinite)
2020-09-26 20:31:48 <pie_> i guess laziness helps
2020-09-26 20:31:58 <monochrom> "similar" is not enough
2020-09-26 20:32:07 <monochrom> C and Rust are "similar".
2020-09-26 20:32:18 <monochrom> Lisp and Agda are "similar"
2020-09-26 20:32:21 <sm[m]> you could prototype it in both haskell and python, for extra insight & testing
2020-09-26 20:32:24 → thir joins (~thir@p200300f27f0fc60094e773283d7bf825.dip0.t-ipconnect.de)
2020-09-26 20:32:27 × knupfer quits (~Thunderbi@200116b82c2b4e00d8f25cb26cf0082b.dip.versatel-1u1.de) (Ping timeout: 240 seconds)
2020-09-26 20:32:30 <monochrom> Tuesday is like Monday, but different.
2020-09-26 20:32:42 <pie_> monochrom: i accept that as fair but i assumed this would be an issue where similar is sufficient
2020-09-26 20:32:47 <Cale> There are only a few problems you can run into though, so asking about how Haskell libraries deal with it isn't bad
2020-09-26 20:32:51 <monochrom> http://www.vex.net/~trebla/humour/tautologies.html
2020-09-26 20:33:13 × Guest_2 quits (59401d45@89-64-29-69.dynamic.chello.pl) (Remote host closed the connection)
2020-09-26 20:33:24 <pie_> if it would not have been sufficient, i assumed i would probably have been told so
2020-09-26 20:33:52 <monochrom> Different parser combinators are going to be very likely disagree on the detailed semantics of <|>. That's where "similar" fails.
2020-09-26 20:34:00 <dolio> Seems like a lot of assumptions going on. :)
2020-09-26 20:34:06 <pie_> and haskell is probably the community with largest overlap between parser combinators and "uh ive got some parser combinator libary in antoher language here :P"
2020-09-26 20:34:13 <pie_> dolio: so it goes, but feedback loops
2020-09-26 20:34:42 <pie_> dolio: i need help with a library but first i must construct the universe ;p
2020-09-26 20:35:09 <monochrom> For example ReadP in base supports ambiguous grammars fully, <|> is perfectly ideal fair choice, all possibilities of "p <|> q" really happen.
2020-09-26 20:35:44 → adam_wespiser joins (~adam_wesp@209.6.42.110)
2020-09-26 20:35:48 <monochrom> But parsec and megaparsec beg to differ. "p <|> q" becomes simply p if p consumes at least one character/token.
2020-09-26 20:35:56 <pie_> (i knew the problem was that the parser wasnt "consumptive" (as opposed to productive :P), but my brain didnt get from point a to point b on actually fixing it till i rubber ducked it i guess. anyway, much ado about nothing)
2020-09-26 20:36:08 <monochrom> (overridable if you use "try p <|> q")
2020-09-26 20:36:37 <pie_> monochrom: i see. so they "commit" it if consumes?
2020-09-26 20:36:43 <monochrom> Yes
2020-09-26 20:36:47 → juuandyy joins (~juuandyy@90.166.144.65)
2020-09-26 20:36:47 × v_m_v quits (~vm_v@2a02:aa12:3200:6480:f507:71a:9334:3099) (Remote host closed the connection)
2020-09-26 20:36:48 <sm[m]> megaparsec has some automatic backtracking but I always forget the details
2020-09-26 20:37:07 <pie_> i might not mind explicit backtracking
2020-09-26 20:37:12 × thir quits (~thir@p200300f27f0fc60094e773283d7bf825.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2020-09-26 20:37:15 <pie_> maybe implicit backtracking is half my issues
2020-09-26 20:37:36 <pie_> at least uhh... i think the library does implicit backtracking...idek
2020-09-26 20:37:42 <pie_> i just know i get stuck a lot :P
2020-09-26 20:37:45 <sm[m]> you're flying blind :)
2020-09-26 20:37:49 <monochrom> A priori I have no reason to believe parsy's <|> behaves as ReadP or as parsec or as something else.
2020-09-26 20:37:58 <pie_> yeah
2020-09-26 20:38:09 <dolio> Could be PEG.
2020-09-26 20:38:32 <monochrom> A posteriori if you have being working at the level of "I think they are all similar" then I know for sure you don't know either.
2020-09-26 20:38:32 <pie_> sm[m]: i did at one point think of rewriting it in haskell but i figured maybe i should get stuck with one thing at at a time :P
←Prev  Next→
Page 1 .. 235 236 237 238 239 240 241 242 243 244 245 .. 5022

All times are in UTC.