Newest at the top
| 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 |
| 2025-11-12 12:55:31 +0100 | <tomsmeding> | for a rather horrific example: when GHC first parses a Haskell file, it doesn't care about operator associativity and just plunks them in a tree somehow. Then it finds all the infixl/infixr etc. declarations, and then it goes over the parsed file again and fixes all the operator trees so that they're correctly associated |
| 2025-11-12 12:54:33 +0100 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-11-12 12:54:09 +0100 | <tomsmeding> | parsing in multiple passes has plenty of precedent |
| 2025-11-12 12:53:44 +0100 | <bwe> | tomsmeding: I realised recently that I need to parse the given string word for word and then go over the result to construct the three cases. (My frustration basically stem from attempting to read the desired abstract representation right away.) |
| 2025-11-12 12:50:36 +0100 | <tomsmeding> | (in effect this is putting one level of concrete syntax between the actual string and your desired abstract representation) |
| 2025-11-12 12:50:24 +0100 | <bwe> | merijn: A list of chemical elements and their compounds. At times, I've got only the elementary form, at times, I've got the compound form, at times both (as multiple words in random order with other words interspersed). I'd like to parse and differentiate the three cases. |
| 2025-11-12 12:49:29 +0100 | jreicher | (~user@user/jreicher) jreicher |
| 2025-11-12 12:49:05 +0100 | <tomsmeding> | bwe: taking a guess as to what you need: perhaps parse have a single parser that parses into a [Either A B], and then post-process that list? |