Newest at the top
| 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? |
| 2025-11-12 12:42:19 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 256 seconds) |
| 2025-11-12 12:37:17 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-12 12:36:33 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2025-11-12 12:36:26 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-11-12 12:35:05 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-12 12:34:45 +0100 | <__monty__> | bwe: Can you be a bit more specific because so far it just sounds like sequencing, no? `lexeme fooParser *> lexeme barParser *> lexeme abParser` |
| 2025-11-12 12:30:26 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-12 12:28:32 +0100 | starving_drummer | (~berke@user/Starving-Drummer:76786) Starving_Drummer |
| 2025-11-12 12:28:19 +0100 | trickard_ | trickard |
| 2025-11-12 12:28:07 +0100 | Googulator38 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-12 12:27:52 +0100 | Googulator38 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-12 12:23:14 +0100 | <merijn> | bwe: What exactly are you trying to parse? |
| 2025-11-12 12:22:58 +0100 | <merijn> | bwe: Yeah, `lookAhead` does what you described wanting, but the real question is "is what you want sensible for a parser" :p |
| 2025-11-12 12:20:02 +0100 | Googulator38 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-12 12:19:47 +0100 | Googulator38 | (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-12 12:19:02 +0100 | <bwe> | merijn: There is `lookAhead`. Though I feel right now I'm trying the wrong problem, I actually need to parse word for word and based on the list should decide whether I have simultaneous occurence of both: "foo bar A foo bar B" should extract "A" and "B" |
| 2025-11-12 12:16:54 +0100 | <merijn> | Is there something like `lookahead` |
| 2025-11-12 12:16:53 +0100 | <bwe> | merijn: It is. How do I feed the same input to two parsers (without resorting to call parseMaybe twice in a wrapper function that's no longer :: Parser ParsedResult)? |
| 2025-11-12 12:15:38 +0100 | <merijn> | bwe: That sounds like the wrong question. Sounds like the real question is "how can I feed the same input to two parsers"? |
| 2025-11-12 12:13:18 +0100 | <bwe> | (I am trying to write a parser that runs two parsers on the same input and it should return only if both parsers are successful) |
| 2025-11-12 12:12:21 +0100 | <bwe> | `try` in Megaparsec backtracks on failure, how can I backtrack on succeeding? https://hackage.haskell.org/package/megaparsec-9.7.0/docs/Text-Megaparsec.html#v:try |
| 2025-11-12 12:11:16 +0100 | acidjnk | (~acidjnk@p200300d6e717198650058a5e82e156ef.dip0.t-ipconnect.de) acidjnk |
| 2025-11-12 12:07:10 +0100 | xff0x | (~xff0x@2405:6580:b080:900:bad6:34c9:62ae:89f7) |
| 2025-11-12 12:03:29 +0100 | <merijn> | BS/LBS/T and M/IM/S/IS for Map, IntMap, Set, and IntSet from containers are all pretty widely used |
| 2025-11-12 12:00:37 +0100 | <haskellbridge> | <Morj> I prefer a way like tŠ¾msmeding said, and using ByteString, LazyByteString, Text instead of abbreviations |
| 2025-11-12 12:00:33 +0100 | <__monty__> | So you litter your code with expletives instead?! : > |
| 2025-11-12 12:00:11 +0100 | <merijn> | Fully written out qualification is for mad men |
| 2025-11-12 11:59:54 +0100 | <merijn> | I always import ByteString/lazy ByteString as BS and LBS respectictively, T for Data.Text, etc. |
| 2025-11-12 11:59:25 +0100 | <merijn> | Morj: I mean some modules are explicitly intended for qualified imports, but generally people use abbreviations |
| 2025-11-12 11:58:06 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |