Logs: liberachat/#haskell
| 2021-05-31 14:33:29 | → | dyeplexer joins (~dyeplexer@user/dyeplexer) |
| 2021-05-31 14:33:43 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-05-31 14:33:44 | × | anandprabhu quits (~anandprab@87.201.97.214) (Quit: Leaving) |
| 2021-05-31 14:33:51 | <ski> | @type (fmap mconcat . sequenceA) [Text.Parsec.option "" (Text.Parsec.string "a"),Text.Parsec.option "" (Text.Parsec.string "b"),Text.Parsec.option "" (Text.Parsec.string "c")] |
| 2021-05-31 14:33:53 | <lambdabot> | Text.Parsec.Prim.Stream s m Char => Text.Parsec.Prim.ParsecT s u m [Char] |
| 2021-05-31 14:34:00 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-05-31 14:34:09 | → | whaletechho joins (~whaletech@user/whaletechno) |
| 2021-05-31 14:34:25 | → | ornxka joins (~ornxka@user/ornxka) |
| 2021-05-31 14:34:50 | → | ruffy_ joins (~jonas@2a03:b0c0:3:d0::162e:a001) |
| 2021-05-31 14:34:51 | → | AgentM joins (~agentm@pool-162-83-130-212.nycmny.fios.verizon.net) |
| 2021-05-31 14:35:14 | × | kuribas quits (~user@ptr-25vy0i7o5gw6tky01tr.18120a2.ip6.access.telenet.be) (Ping timeout: 268 seconds) |
| 2021-05-31 14:35:14 | × | gawen quits (~gawen@user/gawen) (Ping timeout: 268 seconds) |
| 2021-05-31 14:35:46 | → | gawen joins (~gawen@user/gawen) |
| 2021-05-31 14:36:03 | → | kuribas`` joins (~user@ptr-25vy0i7o5gw6tky01tr.18120a2.ip6.access.telenet.be) |
| 2021-05-31 14:36:08 | × | michalz quits (~user@185.246.204.55) (Ping timeout: 268 seconds) |
| 2021-05-31 14:36:50 | <ixlun> | I like it! I didn't think of putting the parsing steps into an array and useing concat! |
| 2021-05-31 14:37:04 | <ski> | s/array/list/ |
| 2021-05-31 14:37:41 | × | atwm quits (~andrew@178.197.235.239) (Ping timeout: 252 seconds) |
| 2021-05-31 14:37:52 | × | fizbin quits (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Remote host closed the connection) |
| 2021-05-31 14:38:01 | <ski> | (if all your parsing actions there are of that form, then something like tdammers' version would be nicer) |
| 2021-05-31 14:38:52 | → | sifu joins (~marek@219.244.200.146.dyn.plus.net) |
| 2021-05-31 14:38:52 | → | shapr joins (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-05-31 14:39:20 | × | koishi_ quits (~koishi_@67.209.186.120.16clouds.com) (Ping timeout: 252 seconds) |
| 2021-05-31 14:40:08 | <jmcarthur> | A semimodule over a semiring consists of a commutative monoid. Does anybody know if the commutativity of the monoid is inevitable from the other axioms or if it's just an extra property? If the latter, is there a name for a semimodule where the monoid is not commutative? |
| 2021-05-31 14:40:12 | <ixlun> | I have to say, having written a full C parser with Bison, using Haskell for writing parsers is a dream! |
| 2021-05-31 14:41:14 | → | michalz joins (~user@185.246.204.45) |
| 2021-05-31 14:41:31 | <jmcarthur> | I have seen a proof that commutativity is inevitable in a module, but it made use of additive inverses. |
| 2021-05-31 14:41:52 | × | kuribas`` quits (~user@ptr-25vy0i7o5gw6tky01tr.18120a2.ip6.access.telenet.be) (*.net *.split) |
| 2021-05-31 14:41:52 | × | AgentM quits (~agentm@pool-162-83-130-212.nycmny.fios.verizon.net) (*.net *.split) |
| 2021-05-31 14:41:52 | × | Tuplanolla quits (~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) (*.net *.split) |
| 2021-05-31 14:41:52 | × | otto_s quits (~user@p5de2fbac.dip0.t-ipconnect.de) (*.net *.split) |
| 2021-05-31 14:41:52 | × | raehik1 quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (*.net *.split) |
| 2021-05-31 14:41:52 | × | Dynom quits (~niels@80-114-12-206.cable.dynamic.v4.ziggo.nl) (*.net *.split) |
| 2021-05-31 14:41:52 | × | werneta quits (~werneta@mobile-166-176-57-108.mycingular.net) (*.net *.split) |
| 2021-05-31 14:41:52 | × | whaletechno quits (~whaletech@user/whaletechno) (*.net *.split) |
| 2021-05-31 14:41:52 | × | farn quits (~farn@2a03:4000:7:3cd:d4ab:85ff:feeb:f505) (*.net *.split) |
| 2021-05-31 14:41:52 | × | np quits (znc@user/nerdypepper) (*.net *.split) |
| 2021-05-31 14:42:05 | → | Lycurgus joins (~juan@cpe-45-46-140-49.buffalo.res.rr.com) |
| 2021-05-31 14:43:19 | → | Dynom joins (~niels@80-114-12-206.cable.dynamic.v4.ziggo.nl) |
| 2021-05-31 14:43:22 | <tdammers> | ixlun: there is a little itty bitty caveat, which is that recursive-descent parsers such as those you write in Parsec tend to perform worse than the kind of parsers you can build with bison/flex (or yacc/lex or whatever) |
| 2021-05-31 14:43:44 | <hpc> | (or in haskell, alex/happy) |
| 2021-05-31 14:43:45 | <tdammers> | though IMO the developer ergonomics you gain are almost always worth it |
| 2021-05-31 14:43:46 | → | werneta joins (~werneta@mobile-166-176-57-108.mycingular.net) |
| 2021-05-31 14:43:50 | <tdammers> | right, yeah |
| 2021-05-31 14:44:02 | → | bfrk joins (~Thunderbi@200116b84534a60005aeadf137ee420f.dip.versatel-1u1.de) |
| 2021-05-31 14:44:08 | <jmcarthur> | I'm asking because I'm trying to work out a notion of "thickness" in alpha compositing, and I want to try to find a reasonable algebraic structure for it. Alpha compositing is not commutative, but I am looking something module-like to talk about thickness. |
| 2021-05-31 14:44:18 | → | nerdypepper joins (znc@152.67.162.71) |
| 2021-05-31 14:45:19 | → | fizbin joins (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) |
| 2021-05-31 14:46:12 | <jmcarthur> | e.g. A thicker layer will be less transparent than a thinner one of the same material. Layering two sheets of equal thickness should be the same as one sheet of twice the thickness. |
| 2021-05-31 14:46:22 | <ixlun> | tdammers: Agreed, I suppose each use case is different but the gains I get with writing a parser in this way far outweighs the performance loss. |
| 2021-05-31 14:46:36 | × | mnrmnaugh quits (~mnrmnaugh@pool-96-252-87-182.bstnma.fios.verizon.net) (Ping timeout: 268 seconds) |
| 2021-05-31 14:46:51 | → | slowButPresent joins (~slowButPr@user/slowbutpresent) |
| 2021-05-31 14:46:55 | ← | bfrk parts (~Thunderbi@200116b84534a60005aeadf137ee420f.dip.versatel-1u1.de) () |
| 2021-05-31 14:47:19 | <tdammers> | ixlun: absolutely. I generally use (mega-)parsec myself, all else being equal |
| 2021-05-31 14:47:37 | → | cheater1__ joins (~Username@user/cheater) |
| 2021-05-31 14:47:47 | <tdammers> | frankly, I have yet to be in a situation where I can't get a recursive-descent parser to perform well enough for my needs. though those situations certainly do exist. |
| 2021-05-31 14:47:51 | <ixlun> | One other question I've got. I've noticed that whenever I use (<|>), I almost always need to prefix the lhs with 'try' so that the rhs parser runs. Why doesn't (<|>) imply try on the lhs, or what is the case where you wouldn't want a try on the lhs? |
| 2021-05-31 14:47:51 | × | cheater quits (~Username@user/cheater) (Ping timeout: 272 seconds) |
| 2021-05-31 14:47:59 | cheater1__ | is now known as cheater |
| 2021-05-31 14:48:45 | <tdammers> | excessive use of "try" leads to useless error messages |
| 2021-05-31 14:49:03 | <jmcarthur> | FWIW, the need to use try is kind of a quirk (not necessarily a flaw) of Parsec. Not all parser combinator libraries require it. |
| 2021-05-31 14:49:17 | <tdammers> | and it can also make parsers more difficult to debug, and lead to performance drains |
| 2021-05-31 14:49:21 | → | kuribas`` joins (~user@ptr-25vy0i7o5gw6tky01tr.18120a2.ip6.access.telenet.be) |
| 2021-05-31 14:49:21 | → | AgentM joins (~agentm@pool-162-83-130-212.nycmny.fios.verizon.net) |
| 2021-05-31 14:49:21 | → | Tuplanolla joins (~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) |
| 2021-05-31 14:49:21 | → | otto_s joins (~user@p5de2fbac.dip0.t-ipconnect.de) |
| 2021-05-31 14:49:21 | → | raehik1 joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-05-31 14:49:21 | → | farn joins (~farn@2a03:4000:7:3cd:d4ab:85ff:feeb:f505) |
| 2021-05-31 14:49:41 | <tdammers> | you should only wrap in "try" those parts of your parsers that you need to backtrack on in case they don't succeed |
| 2021-05-31 14:50:18 | × | fizbin quits (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Ping timeout: 268 seconds) |
| 2021-05-31 14:50:24 | → | pavonia joins (~user@user/siracusa) |
| 2021-05-31 14:50:43 | <tdammers> | for example, if you have a parser like string "{{" *> someExpression <* string "}}", then you don't want to wrap the whole thing in try, but rather just the first bit (the string "{{") part, because once you have seen a "{{", you are committed to parsing a {{ }} block |
| 2021-05-31 14:50:44 | <jmcarthur> | You can sometimes avoid using try, or at least avoid backtracking really far, with some thoughtful refactoring. |
| 2021-05-31 14:50:55 | <jmcarthur> | ^^ yeah like that |
| 2021-05-31 14:52:22 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-05-31 14:52:28 | <ixlun> | Right, so 'try' gives you control over when to backtrack. |
| 2021-05-31 14:52:32 | <tdammers> | megaparsec, unlike parsec, implicitly wraps more constructs in try, so you don't need to explicitly try very often, at least if your parser is structured somewhat nicely, and the grammar isn't insane |
| 2021-05-31 14:52:43 | × | sondre quits (~sondrelun@eduroam-193-157-203-145.wlan.uio.no) (Ping timeout: 272 seconds) |
| 2021-05-31 14:53:08 | <tdammers> | yes. "try" means "if the argument fails, undo any consuming the argument may have done, and then fail" |
| 2021-05-31 14:53:49 | <ixlun> | One thing that would be nice to see is if you could pass a set of megaparsec combinators to a program and it spits out the grammar for you. I know Bison gives you a really nice print out of your grammar in debug mode. |
| 2021-05-31 14:54:00 | × | gehmehgeh quits (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2021-05-31 14:54:16 | <tdammers> | so, say you write a parser like so: string "hello" <|> string "world". And now you feed it the input "helo". The lhs is tried first, and it starts consuming things as long as they match: h, e, l, but then it sees "o" where it expects "l", and fails |
| 2021-05-31 14:54:37 | <tdammers> | but at that point, it has already consumed 3 characters from the input, and that isn't undone as you head into the rhs of the <|> |
| 2021-05-31 14:54:50 | → | gehmehgeh joins (~user@user/gehmehgeh) |
| 2021-05-31 14:54:58 | <tdammers> | so the rhs now starts working on the remaining input, "o", instead of the whole thing, "helo", as it should have |
| 2021-05-31 14:55:00 | → | mnrmnaugh joins (~mnrmnaugh@pool-96-252-87-182.bstnma.fios.verizon.net) |
| 2021-05-31 14:55:28 | <jmcarthur> | In order to spit out a grammar like that, the interface could not be monadic, at least not in the way parsec is. It's more plausible for a less powerful combinator library to do this, though. |
| 2021-05-31 14:55:32 | <tdammers> | however, wrap the lhs in "try", and it will backtrack when it fails, rolling back to the input reading "helo", and the rhs operates on that |
| 2021-05-31 14:56:33 | <hpc> | in other words, (string "hello" <|> string "world") will successfully parse "helworld" |
| 2021-05-31 14:57:30 | <jmcarthur> | Hmm... maybe there are other problems with my semimodule idea. It's not clear to me that thickness*(a + b) should be the same as thickness*a + thickness*b. |
| 2021-05-31 14:58:08 | <ixlun> | Ah interesting. so by not using 'try' you may parse inputs that you aren't expecting too |
| 2021-05-31 14:58:52 | <hpc> | jmcarthur: think of it as sequencing operations, maybe? |
| 2021-05-31 14:59:16 | → | notzmv joins (~zmv@user/notzmv) |
| 2021-05-31 15:00:35 | → | sondre joins (~sondrelun@eduroam-193-157-203-145.wlan.uio.no) |
| 2021-05-31 15:00:38 | <ski> | % parse (string "hello" <|> string "world") "" "helworld" |
| 2021-05-31 15:00:38 | <yahb> | ski: Left (line 1, column 1):; unexpected "w"; expecting "hello" |
| 2021-05-31 15:00:58 | → | favonia joins (~favonia@user/favonia) |
| 2021-05-31 15:01:11 | <jmcarthur> | hpc: If thickness was restricted to natural numbers, sure, and I could just stick with a monoid for the whole thing, but I am trying to come up with an approach that allows thicknesses to be nonnegative reals. |
| 2021-05-31 15:01:28 | <jmcarthur> | My plan is to try to define that (*) operation, once I figure out what its properties should be. |
| 2021-05-31 15:02:05 | × | cheater quits (~Username@user/cheater) (Ping timeout: 264 seconds) |
All times are in UTC.