2026/02/11

Newest at the top

2026-02-11 15:16:59 +0100Enrico63(~Enrico63@host-79-22-157-220.retail.telecomitalia.it) (Ping timeout: 272 seconds)
2026-02-11 15:10:28 +0100kimiamania4(~b4b260c9@user/kimiamania) kimiamania
2026-02-11 15:10:08 +0100kimiamania4(~b4b260c9@user/kimiamania) (Server closed connection)
2026-02-11 15:09:13 +0100ljdarj(~Thunderbi@user/ljdarj) ljdarj
2026-02-11 15:05:36 +0100Googulator(~Googulato@2a01-036d-0106-216f-6164-ec92-51a0-9cde.pool6.digikabel.hu)
2026-02-11 15:05:19 +0100Googulator(~Googulato@2a01-036d-0106-216f-6164-ec92-51a0-9cde.pool6.digikabel.hu) (Quit: Client closed)
2026-02-11 15:02:38 +0100mzg_mzg
2026-02-11 15:00:45 +0100infinity0(~infinity0@pwned.gg) (Ping timeout: 245 seconds)
2026-02-11 14:57:19 +0100housemate(~housemate@2001:8004:6970:4f3c:c4f4:395a:ec93:7dc) housemate
2026-02-11 14:49:33 +0100pr1sm(~pr1sm@24.91.163.31)
2026-02-11 14:32:13 +0100emaczen(~user@user/emaczen) emaczen
2026-02-11 14:28:28 +0100rekahsoft(~rekahsoft@bras-base-orllon1103w-grc-20-76-67-111-168.dsl.bell.ca) rekahsoft
2026-02-11 14:27:25 +0100_________(~nobody@user/noodly) _________
2026-02-11 14:26:43 +0100_________(~nobody@user/noodly) (Ping timeout: 260 seconds)
2026-02-11 14:26:32 +0100trickard(~trickard@cpe-54-98-47-163.wireline.com.au) (Remote host closed the connection)
2026-02-11 14:26:14 +0100fp(~Thunderbi@130.233.70.158) fp
2026-02-11 14:22:31 +0100Square(~Square4@user/square) Square
2026-02-11 14:10:03 +0100juri_(~juri@212.86.50.13) (Read error: Connection reset by peer)
2026-02-11 14:09:50 +0100juri_(~juri@212.86.50.13) juri_
2026-02-11 14:06:38 +0100APic(apic@apic.name) APic
2026-02-11 14:06:04 +0100 <gentauro> ski: got it
2026-02-11 14:05:02 +0100omnifunctor(~omnifunct@user/semifunctor) omnifunctor
2026-02-11 14:04:48 +0100omnifunctor(~omnifunct@user/semifunctor) (Server closed connection)
2026-02-11 14:04:25 +0100juri_(~juri@212.86.50.13) (Read error: Connection reset by peer)
2026-02-11 14:04:15 +0100juri_(~juri@212.86.50.13) juri_
2026-02-11 14:03:29 +0100 <ski> well, i said "no [..] `lookAhead'"
2026-02-11 14:02:45 +0100 <gentauro> ski: with `lookAhead` you bind your parser logic to a monadic context right? Isn't it better su rely only on (Selective) Applicative and Functors?
2026-02-11 14:01:28 +0100APic(apic@apic.name) (Server closed connection)
2026-02-11 13:58:47 +0100juri_(~juri@212.86.50.13) (Read error: Connection reset by peer)
2026-02-11 13:58:47 +0100lisbeths(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2026-02-11 13:58:39 +0100juri_(~juri@212.86.50.13) juri_
2026-02-11 13:57:26 +0100prdak(~Thunderbi@user/prdak) (Ping timeout: 252 seconds)
2026-02-11 13:56:19 +0100rensenwxrefwam
2026-02-11 13:52:57 +0100prdak(~Thunderbi@user/prdak) prdak
2026-02-11 13:46:45 +0100karenw(~karenw@user/karenw) karenw
2026-02-11 13:44:06 +0100driib3180(~driib@vmi931078.contaboserver.net) driib
2026-02-11 13:43:28 +0100driib3180(~driib@vmi931078.contaboserver.net) (Server closed connection)
2026-02-11 13:38:04 +0100Beowulf(florian@2a01:4f9:3b:2d56::2)
2026-02-11 13:37:28 +0100Beowulf(florian@2a01:4f9:3b:2d56::2) (Server closed connection)
2026-02-11 13:35:00 +0100fp(~Thunderbi@wireless-86-50-141-104.open.aalto.fi) (Ping timeout: 252 seconds)
2026-02-11 13:34:33 +0100 <ski> (oh, and it should satisfy the right (and left, upto permutation of solutions) distribution law, and also the law that if `p' parses tokens `s' and `q' parses tokens `t', then `p >> q' ought to parse tokens `s <> t' (so, no `eof' nor `lookAhead'))
2026-02-11 13:31:28 +0100tremon(~tremon@83.80.159.219) tremon
2026-02-11 13:30:53 +0100fp(~Thunderbi@wireless-86-50-141-104.open.aalto.fi) fp
2026-02-11 13:29:53 +0100skiwould like a mode & determinism tracking system that could be used to ensure that you get the intended efficient switching rather than backtracking, when you expect it, without removing the more general case, nor making it less convenient to express
2026-02-11 13:27:41 +0100 <tomsmeding> but I also have to be honest that if you make things more explicit, the whole system doesn't necessarily get nicer -- the rule does somehow strike a balance where a lot of cases can be expressed fairly neatly
2026-02-11 13:26:58 +0100 <tomsmeding> I'm not a fan of this model of "backtracking is an error without consuming input", as it's unintuitive and at times inflexible; I prefer my parser combinators more explicit about backtracking and failure
2026-02-11 13:26:05 +0100 <tomsmeding> or ("abc" >> eof), if appropriate
2026-02-11 13:25:45 +0100 <tomsmeding> ("abc" >> notFollowedBy "d"), for example
2026-02-11 13:25:31 +0100 <tomsmeding> The solutions here seem to be swapping the two parsers (in which case the try shouldn't be necessary any more), or augmenting the "abc" parser to explicitly reject a following 'd'
2026-02-11 13:24:44 +0100 <tomsmeding> error.