Newest at the top
| 2025-11-12 13:59:46 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-11-12 13:59:22 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2025-11-12 13:53:51 +0100 | <lucabtz> | it doesnt seem too hard, but still there seem to be some challenge in having to deal with preexisting code. also i think i could be motivated by the fact it would actually be useful to someone |
| 2025-11-12 13:52:36 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-12 13:52:33 +0100 | <kuribas> | lucabtz: sure |
| 2025-11-12 13:51:52 +0100 | <lucabtz> | do you think writing a pandoc writer could be a good exercise to practice some haskell? |
| 2025-11-12 13:48:38 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-11-12 13:47:40 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 244 seconds) |
| 2025-11-12 13:45:38 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-11-12 13:44:35 +0100 | lucabtz | (~lucabtz@user/lucabtz) lucabtz |
| 2025-11-12 13:44:31 +0100 | <__monty__> | It's usually so flexible that when you run into a hard constraint it feels worse. |
| 2025-11-12 13:43:56 +0100 | <__monty__> | It has some difficult nuances but TBH I think it's a bit of a victim of its own success. |
| 2025-11-12 13:43:12 +0100 | <kuribas> | Look how many people have difficulty with layout-rule. |
| 2025-11-12 13:42:48 +0100 | <kuribas> | __monty__: not just computers... |
| 2025-11-12 13:42:37 +0100 | <__monty__> | At least for computers. |
| 2025-11-12 13:42:27 +0100 | <__monty__> | Great for parsing but hard to parse. |
| 2025-11-12 13:40:43 +0100 | Googulator42 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-12 13:40:43 +0100 | Googulator26 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-12 13:40:42 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-12 13:37:47 +0100 | laxmik | (~user@pc192b.fzu.cz) laxmik |
| 2025-11-12 13:36:54 +0100 | bwe | was told that Haskell being a language great for parsing. |
| 2025-11-12 13:35:43 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-11-12 13:31:39 +0100 | lucabtz | (~lucabtz@user/lucabtz) (Ping timeout: 244 seconds) |
| 2025-11-12 13:29:16 +0100 | <kuribas> | tomsmeding: and I think haskell parsing is complicated enough :) |
| 2025-11-12 13:28:45 +0100 | <tomsmeding> | (not necessarily a good idea for readability) |
| 2025-11-12 13:28:39 +0100 | <tomsmeding> | then exercise: fuse the passes :p |
| 2025-11-12 13:28:11 +0100 | <kuribas> | tomsmeding: that sounds sensible. Multiple phases are easier than putting everything in a single phase. |
| 2025-11-12 13:25:43 +0100 | Googulator99 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-12 13:25:42 +0100 | Googulator26 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-12 13:25:08 +0100 | fp | (~Thunderbi@2001:708:20:1406::1370) fp |
| 2025-11-12 13:24:48 +0100 | fp | (~Thunderbi@2001:708:20:1406::1370) (Client Quit) |
| 2025-11-12 13:23:45 +0100 | fp | (~Thunderbi@2001:708:20:1406::1370) fp |
| 2025-11-12 13:23:22 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:5c5a:fd15:b892:dc7c) |
| 2025-11-12 13:23:17 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-11-12 13:23:07 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:98a2:6042:92fc:d969) (Remote host closed the connection) |
| 2025-11-12 13:22:16 +0100 | fp | (~Thunderbi@130.233.70.206) (Remote host closed the connection) |
| 2025-11-12 13:10:43 +0100 | Googulator99 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-12 13:10:40 +0100 | Googulator | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-12 13:03:19 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:98a2:6042:92fc:d969) |
| 2025-11-12 13:03:05 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:9a6c:1796:18b4:82bc) (Remote host closed the connection) |
| 2025-11-12 12:59:35 +0100 | <Lycurgus> | the antedeluvian days b4 aho and ullman |
| 2025-11-12 12:58:16 +0100 | Googulator38 | Googulator |
| 2025-11-12 12:57:58 +0100 | <Lycurgus> | since like forever parsing and compiling has involved a min of 2, lex then parse |
| 2025-11-12 12:57:38 +0100 | <tomsmeding> | *Either String Result, of course |
| 2025-11-12 12:57:22 +0100 | <tomsmeding> | bwe: in your case I expect the second pass to be a pure function, not a parser, although that pure function might return an Error String Result |
| 2025-11-12 12:57:08 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-11-12 12:56:56 +0100 | <bwe> | How does the second pass still have the type `:: Parser Result` and refrains from calling functions like `parseMaybe`? |
| 2025-11-12 12:56:54 +0100 | <Lycurgus> | single pass: easy job |
| 2025-11-12 12:56:51 +0100 | <tomsmeding> | for a somewhat related idea, though not quite the same, see nanopass compilation |
| 2025-11-12 12:56:16 +0100 | <tomsmeding> | "horrific" as in "if you haven't realised this is happening you think 'surely this can be done better'", not as in "this is a bad solution", because it's a very sensible solution to the problem of user-specified operator associativities |