Logs: liberachat/#haskell
| 2021-05-26 16:00:08 | × | sondre quits (~sondrelun@eduroam-193-157-179-99.wlan.uio.no) (Ping timeout: 252 seconds) |
| 2021-05-26 16:00:24 | → | andreabedini joins (~andreabed@8s8kj6nsk928qlw9thck.ip6.superloop.com) |
| 2021-05-26 16:00:33 | → | jolly joins (~jolly@208.180.97.158) |
| 2021-05-26 16:01:30 | × | pera quits (~pera@user/pera) (Read error: Connection reset by peer) |
| 2021-05-26 16:03:20 | → | nan` joins (~nan`@rrcs-70-60-83-42.central.biz.rr.com) |
| 2021-05-26 16:03:21 | × | nan` quits (~nan`@rrcs-70-60-83-42.central.biz.rr.com) (Client Quit) |
| 2021-05-26 16:04:20 | → | sondre joins (~sondrelun@eduroam-193-157-179-99.wlan.uio.no) |
| 2021-05-26 16:05:14 | → | imdoor joins (~imdoor@balticom-142-78-50.balticom.lv) |
| 2021-05-26 16:05:27 | × | bfrk quits (~Thunderbi@200116b8453bc10024c96ca01cd76d14.dip.versatel-1u1.de) (Ping timeout: 244 seconds) |
| 2021-05-26 16:06:12 | <nsilv> | rofl |
| 2021-05-26 16:06:29 | → | otoburb joins (~otoburb@user/otoburb) |
| 2021-05-26 16:07:57 | × | taeaad quits (~taeaad@user/taeaad) (Quit: ZNC 1.7.5+deb4 - https://znc.in) |
| 2021-05-26 16:07:59 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-05-26 16:08:44 | → | lordgothington joins (~lordgothi@c-73-20-168-111.hsd1.ga.comcast.net) |
| 2021-05-26 16:09:15 | × | sondre quits (~sondrelun@eduroam-193-157-179-99.wlan.uio.no) (Ping timeout: 264 seconds) |
| 2021-05-26 16:09:38 | → | Guest56 joins (~Guest56@103.red-83-32-250.dynamicip.rima-tde.net) |
| 2021-05-26 16:09:54 | ← | Guest56 parts (~Guest56@103.red-83-32-250.dynamicip.rima-tde.net) () |
| 2021-05-26 16:09:54 | × | hr0m quits (~hr0m@2a03:4000:6:446f:899:53ff:fe87:3ffe) (Quit: WeeChat 2.3) |
| 2021-05-26 16:10:05 | × | imdoor quits (~imdoor@balticom-142-78-50.balticom.lv) (Client Quit) |
| 2021-05-26 16:10:18 | → | taeaad joins (~taeaad@user/taeaad) |
| 2021-05-26 16:10:52 | <Schrostfutz> | I'm trying to wrap my head around a problem with parsing: Say I have three parsers that return distinct types and I know I can use all of them in succession, just not in which order, how could I implement that? I struggle to come up with a proper solution. My current thought process is to implement an n-ary Either Parser, use partition on that and ensure that the resulting lists are each singletons. But my intuition tells me that's |
| 2021-05-26 16:10:52 | <Schrostfutz> | quite elaborate for the goal. |
| 2021-05-26 16:11:11 | × | lordgothington quits (~lordgothi@c-73-20-168-111.hsd1.ga.comcast.net) (Client Quit) |
| 2021-05-26 16:11:11 | × | tonyz quits (~tonyz@user/tonyz) (Quit: Leaving) |
| 2021-05-26 16:11:56 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:c80c:b901:dda5:784c) (Ping timeout: 265 seconds) |
| 2021-05-26 16:13:06 | → | hnOsmium0001 joins (uid453710@id-453710.stonehaven.irccloud.com) |
| 2021-05-26 16:13:50 | × | chele quits (~chele@user/chele) (Remote host closed the connection) |
| 2021-05-26 16:13:56 | <hololeap> | Schrostfutz: you would have to create a sum type that enumerates each of them and then hold some kind of state so that you can check that they don't repeat during parsing. I think that's how you would have to do it |
| 2021-05-26 16:13:57 | → | waleee joins (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-05-26 16:14:37 | → | barrucadu joins (~barrucadu@carcosa.barrucadu.co.uk) |
| 2021-05-26 16:14:41 | <hololeap> | assuming you don't want repeats of the three types. If you _do_ allow that it will be much simpler |
| 2021-05-26 16:14:54 | → | atwm joins (~andrew@19-193-28-81.ftth.cust.kwaoo.net) |
| 2021-05-26 16:15:07 | <davean> | Schrostfutz: I mean try a list of parsers, try the next list of parsers, etc? Just because you don't know what order you'll parse them in doesn't mean you have to store them out of order |
| 2021-05-26 16:15:16 | <davean> | you can fill in a datastructure with a fixed order |
| 2021-05-26 16:15:17 | <hololeap> | Although, it would make sense to have each type in a specified order |
| 2021-05-26 16:15:48 | <davean> | he said "singletons" so I think he means without replacement |
| 2021-05-26 16:16:30 | <Schrostfutz> | hololeap: No, all of them should be present exactly once. The problem is, that I'm parsing a protocol that doesn't specify the order, even though in practice it will always be the same... |
| 2021-05-26 16:16:49 | × | Franciman quits (~francesco@host-80-180-196-134.pool80180.interbusiness.it) (Quit: Leaving) |
| 2021-05-26 16:16:53 | <davean> | but if you start with a function \_ _ _ _ -> result, you can fill in the holes, and wrap at each step with a function that takes reuse of the filled in entries to errors or something |
| 2021-05-26 16:17:08 | <davean> | that is if each parameter is maybe |
| 2021-05-26 16:17:14 | <davean> | Like theres a lot of ways to do this |
| 2021-05-26 16:17:22 | <hololeap> | in that case you probably want to create a sum type with an Ord instance, then pass along a Set as your state so that you can keep track of them. |
| 2021-05-26 16:17:47 | × | enchoi quits (~textual@2403:6200:8876:ee80:d1f8:2f2f:4629:dfc9) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-05-26 16:18:13 | → | Aran joins (~Aran@port-92-194-80-170.dynamic.as20676.net) |
| 2021-05-26 16:18:59 | → | defunctor joins (~textual@2405:6580:b1c0:2500:3c98:f151:a0d9:62c7) |
| 2021-05-26 16:19:15 | × | atwm quits (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Quit: WeeChat 3.1) |
| 2021-05-26 16:19:20 | <Schrostfutz> | To avoid the x-y problem: I'm parsing a protocol that's a list of commands which each have a list of attributes. I implemented a generic version of this (i.e. having a Command & Attribute product type), now I want to extend is to interpret the individual commands (i.e. FooCommand, BarCommand as sum type) because the set of attributes for each command is well-defined. |
| 2021-05-26 16:19:38 | → | gambpang joins (~ian@207.181.230.156) |
| 2021-05-26 16:19:51 | <hololeap> | are you using any particular library to parse it |
| 2021-05-26 16:19:58 | × | nsilv quits (~nsilv@host-82-50-119-12.retail.telecomitalia.it) (Ping timeout: 264 seconds) |
| 2021-05-26 16:20:14 | <davean> | Well, why aren't you just processing a list of commands like they came in then? |
| 2021-05-26 16:20:30 | <Schrostfutz> | davean: I like the idea of successively filling in the holes, but this way I'd have to specify each set individually, right? |
| 2021-05-26 16:20:37 | <Schrostfutz> | hololeap: Yes, attoparsec |
| 2021-05-26 16:20:45 | → | atwm joins (~andrew@19-193-28-81.ftth.cust.kwaoo.net) |
| 2021-05-26 16:20:50 | → | sedeki joins (~textual@user/sedeki) |
| 2021-05-26 16:21:20 | <Schrostfutz> | davean: My goal is to interpret the commands, so I'd like to represent their semantic in my datastructure. |
| 2021-05-26 16:21:29 | <hololeap> | If I'm not mistaken, attoparsec isn't monadic and hence cannot have state passed, so you'll have to parse it as a list and then validate it afterwards, I think |
| 2021-05-26 16:21:52 | → | tzh joins (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2021-05-26 16:22:12 | <davean> | uh, what? A) yes it is, B) what? How can you not pass state without a monad? Just pass a continuation like I was talking about above. |
| 2021-05-26 16:22:32 | → | econo joins (uid147250@user/econo) |
| 2021-05-26 16:23:05 | <hololeap> | my understanding was that for a parser to change its behavior based on a previous "piece", it had to be monadic |
| 2021-05-26 16:23:33 | → | ddellacosta joins (~ddellacos@89.46.62.53) |
| 2021-05-26 16:23:35 | <davean> | Of course not, but also attoparsec is |
| 2021-05-26 16:23:38 | <hololeap> | Parser a -> (a -> Parser b) -> Parser b |
| 2021-05-26 16:23:48 | <davean> | I mean theres a monadic concept one might related here |
| 2021-05-26 16:23:55 | <davean> | but it can break the laws and still do all that |
| 2021-05-26 16:24:17 | × | boxscape quits (~boxscape@user/boxscape) (Quit: Connection closed) |
| 2021-05-26 16:24:22 | <davean> | and it defiantely doesn't have to be Haskell Monad |
| 2021-05-26 16:25:28 | × | waleee quits (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Ping timeout: 265 seconds) |
| 2021-05-26 16:25:29 | → | deadmeme joins (~deadmeme@61.247.51.245) |
| 2021-05-26 16:26:16 | <hololeap> | right, attoparsec just doesn't have a monad _transformer_ |
| 2021-05-26 16:26:50 | → | alberto joins (~user@2001:b07:a96:75b9:be3e:73f7:1e58:8e12) |
| 2021-05-26 16:26:57 | <hololeap> | but I'm also not seeing anything about carrying custom state in the docs |
| 2021-05-26 16:27:01 | <davean> | a monad transformer is entirely different than Monad, and attoparsec is a Monad, but even if it wasn't that wouldn't be really relivent. |
| 2021-05-26 16:27:15 | ← | alberto parts (~user@2001:b07:a96:75b9:be3e:73f7:1e58:8e12) () |
| 2021-05-26 16:27:18 | <hololeap> | it is very relevant |
| 2021-05-26 16:27:23 | <davean> | Haskell is a functional language |
| 2021-05-26 16:27:46 | → | pretty_dumm_guy joins (~trottel@185.244.212.62) |
| 2021-05-26 16:27:48 | <hololeap> | the sky is blue? |
| 2021-05-26 16:28:10 | <zzz> | davean: depending on your definition of functional ;) |
| 2021-05-26 16:28:18 | <davean> | I mean I just gave you the solution directly |
| 2021-05-26 16:28:28 | <davean> | use a function as a first class object |
| 2021-05-26 16:28:44 | <davean> | Ypi |
| 2021-05-26 16:28:47 | <davean> | You're done |
| 2021-05-26 16:28:51 | × | ubert quits (~Thunderbi@2a02:8109:9880:303c:ca5b:76ff:fe29:f233) (Ping timeout: 265 seconds) |
| 2021-05-26 16:28:58 | × | mikoto-chan quits (~mikoto-ch@ip-213-49-189-31.dsl.scarlet.be) (Ping timeout: 264 seconds) |
| 2021-05-26 16:29:15 | <davean> | Most of attoparsec's haddocks demonstrate this |
| 2021-05-26 16:29:35 | <davean> | I was talking about it to begin with |
| 2021-05-26 16:29:38 | <davean> | just pass along operations |
| 2021-05-26 16:29:51 | <davean> | But, also, if you want to use the tools you're thinking of, thats fine |
| 2021-05-26 16:29:54 | <davean> | attoparsec is a monad |
| 2021-05-26 16:30:00 | <hololeap> | right, you have to parse, then validate. with something like megaparsec, you could pass along a custom state and fail if you parsed the same type twice |
| 2021-05-26 16:30:01 | <davean> | so you use the state transformer *over* that |
| 2021-05-26 16:30:04 | <davean> | not the other way around |
| 2021-05-26 16:30:13 | <davean> | semanticly it *can't* be the other way around |
| 2021-05-26 16:30:20 | <davean> | no |
| 2021-05-26 16:30:25 | → | brightside joins (~brightsid@106.192.139.228) |
| 2021-05-26 16:30:27 | <davean> | You didn't listen |
| 2021-05-26 16:30:31 | <davean> | I give up |
| 2021-05-26 16:30:42 | <davean> | I specificly directly contradicted that |
All times are in UTC.