2025/08/04

Newest at the top

2025-08-04 11:05:13 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 252 seconds)
2025-08-04 11:03:56 +0200trickard_(~trickard@cpe-56-98-47-163.wireline.com.au)
2025-08-04 11:03:42 +0200trickard_(~trickard@cpe-56-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-08-04 10:59:47 +0200merijn(~merijn@77.242.116.146) merijn
2025-08-04 10:54:45 +0200haritz(~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in)
2025-08-04 10:54:01 +0200chele(~chele@user/chele) chele
2025-08-04 10:51:16 +0200mm_x_(~mm@user/mm-x-:64963) (Client Quit)
2025-08-04 10:50:29 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 248 seconds)
2025-08-04 10:47:39 +0200mm_x_(~mm@user/mm-x-:64963) mm_x_
2025-08-04 10:45:59 +0200tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2025-08-04 10:45:34 +0200merijn(~merijn@77.242.116.146) merijn
2025-08-04 10:44:55 +0200ubert(~Thunderbi@91.141.76.34.wireless.dyn.drei.com) ubert
2025-08-04 10:37:20 +0200caubert(~caubert@user/caubert) caubert
2025-08-04 10:35:58 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 244 seconds)
2025-08-04 10:27:14 +0200visilii(~visilii@85.172.77.40)
2025-08-04 10:24:46 +0200trickard_(~trickard@cpe-56-98-47-163.wireline.com.au)
2025-08-04 10:24:33 +0200trickard_(~trickard@cpe-56-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-08-04 10:22:25 +0200merijn(~merijn@77.242.116.146) merijn
2025-08-04 10:21:58 +0200caubert(~caubert@user/caubert) (Ping timeout: 240 seconds)
2025-08-04 10:20:29 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 260 seconds)
2025-08-04 10:20:06 +0200lxsameer(~lxsameer@Serene/lxsameer) lxsameer
2025-08-04 10:15:32 +0200merijn(~merijn@77.242.116.146) merijn
2025-08-04 10:14:44 +0200 <jreicher> They do seem to be a special case, but having had this conversation I realise I've never seen a proper treatment of them. Is there one?
2025-08-04 10:05:28 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 252 seconds)
2025-08-04 09:59:40 +0200 <[exa]> spoiler: macrolanguages are either properly layered or a total mess
2025-08-04 09:59:06 +0200tromp(~textual@2001:1c00:3487:1b00:9931:a689:a59b:4288) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-08-04 09:57:03 +0200kuribas(~user@ptr-17d51en0t2ys02oeif7.18120a2.ip6.access.telenet.be) kuribas
2025-08-04 09:48:15 +0200Fijxu(~Fijxu@user/fijxu) fijxu
2025-08-04 09:46:39 +0200merijn(~merijn@77.242.116.146) merijn
2025-08-04 09:41:14 +0200Fijxu(~Fijxu@user/fijxu) (Ping timeout: 260 seconds)
2025-08-04 09:40:45 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac
2025-08-04 09:40:18 +0200euouae(~euouae@user/euouae) ()
2025-08-04 09:37:56 +0200trickard_(~trickard@cpe-56-98-47-163.wireline.com.au)
2025-08-04 09:37:42 +0200trickard(~trickard@cpe-56-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-08-04 09:37:09 +0200werneta(~werneta@syn-071-083-160-242.res.spectrum.com) (Ping timeout: 276 seconds)
2025-08-04 09:33:26 +0200 <euouae> That's the plan indeed
2025-08-04 09:33:02 +0200 <jreicher> Then I would suggest you do a parse to get the first action, perform the action to produce a new string to parse, and restart
2025-08-04 09:32:57 +0200 <Leary> I think the lesson here is: let's not apply common sense to pathological languages.
2025-08-04 09:32:34 +0200 <euouae> Yes, you push back on to the stream
2025-08-04 09:32:17 +0200 <euouae> Ultimately, because I have to go, if you have something in mind to suggest, like a library, I'll take your suggestion and look into it. Otherwise, I'll give megaparsec with getInput and setInput a go, and if that does not work, I'll use Attoparsec or other.
2025-08-04 09:32:03 +0200 <jreicher> That's why I was asking if you push back on to the stream. I'm wondering if it makes sense to treat the "state change" wrought by some of these macro evaluations as a feeding the result into a brand new parse.
2025-08-04 09:31:01 +0200 <euouae> there's changecom() and changequote() for example, changing the syntax of strings and comments
2025-08-04 09:30:45 +0200 <euouae> You can't, because the parser depends on the state
2025-08-04 09:30:06 +0200 <jreicher> Because you can keep your parser logic out of your macro evaluation machine, possibly simplifying both
2025-08-04 09:29:51 +0200trickard_trickard
2025-08-04 09:29:33 +0200 <jreicher> Honestly, it might not, but considering the channel we're in I'll say that some people (myself included) believe that it's helpful to separate these things in the mind and also in the code.
2025-08-04 09:29:33 +0200 <euouae> You're just reframing it. I said parser with state, you're saying parsing and evaluation, it doesn't matter. How does any of this get me closer to actually implementing it?
2025-08-04 09:29:06 +0200ft(~ft@mue-88-130-105-177.dsl.tropolys.de) ft
2025-08-04 09:28:38 +0200 <euouae> But what does it matter what they're called?
2025-08-04 09:28:27 +0200 <jreicher> Yeah that sounds like execution of directives rather than just parsing