Logs: liberachat/#haskell
| 2025-11-12 10:59:54 | <merijn> | I always import ByteString/lazy ByteString as BS and LBS respectictively, T for Data.Text, etc. |
| 2025-11-12 11:00:11 | <merijn> | Fully written out qualification is for mad men |
| 2025-11-12 11:00:33 | <__monty__> | So you litter your code with expletives instead?! : > |
| 2025-11-12 11:00:37 | <haskellbridge> | <Morj> I prefer a way like tоmsmeding said, and using ByteString, LazyByteString, Text instead of abbreviations |
| 2025-11-12 11:03:29 | <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 11:07:10 | → | xff0x joins (~xff0x@2405:6580:b080:900:bad6:34c9:62ae:89f7) |
| 2025-11-12 11:11:16 | → | acidjnk joins (~acidjnk@p200300d6e717198650058a5e82e156ef.dip0.t-ipconnect.de) |
| 2025-11-12 11:12:21 | <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 11:13:18 | <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 11:15:38 | <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 11:16:53 | <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 11:16:54 | <merijn> | Is there something like `lookahead` |
| 2025-11-12 11:19:02 | <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 11:19:47 | × | Googulator38 quits (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-12 11:20:02 | → | Googulator38 joins (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-12 11:22:58 | <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 11:23:14 | <merijn> | bwe: What exactly are you trying to parse? |
| 2025-11-12 11:27:52 | × | Googulator38 quits (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-12 11:28:07 | → | Googulator38 joins (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-12 11:28:19 | trickard_ | is now known as trickard |
| 2025-11-12 11:28:32 | → | starving_drummer joins (~berke@user/Starving-Drummer:76786) |
| 2025-11-12 11:30:26 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-12 11:34:45 | <__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 11:35:05 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 2025-11-12 11:36:26 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-11-12 11:36:33 | → | Pozyomka joins (~pyon@user/pyon) |
| 2025-11-12 11:37:17 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 2025-11-12 11:42:19 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 256 seconds) |
| 2025-11-12 11:49:05 | <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 11:49:29 | → | jreicher joins (~user@user/jreicher) |
| 2025-11-12 11:50:24 | <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 11:50:36 | <tomsmeding> | (in effect this is putting one level of concrete syntax between the actual string and your desired abstract representation) |
| 2025-11-12 11:53:44 | <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 11:54:09 | <tomsmeding> | parsing in multiple passes has plenty of precedent |
| 2025-11-12 11:54:33 | → | Lycurgus joins (~juan@user/Lycurgus) |
| 2025-11-12 11:55:31 | <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 11:56:16 | <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 11:56:51 | <tomsmeding> | for a somewhat related idea, though not quite the same, see nanopass compilation |
| 2025-11-12 11:56:54 | <Lycurgus> | single pass: easy job |
| 2025-11-12 11:56:56 | <bwe> | How does the second pass still have the type `:: Parser Result` and refrains from calling functions like `parseMaybe`? |
| 2025-11-12 11:57:08 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-11-12 11:57:22 | <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 11:57:38 | <tomsmeding> | *Either String Result, of course |
| 2025-11-12 11:57:58 | <Lycurgus> | since like forever parsing and compiling has involved a min of 2, lex then parse |
| 2025-11-12 11:58:16 | Googulator38 | is now known as Googulator |
| 2025-11-12 11:59:35 | <Lycurgus> | the antedeluvian days b4 aho and ullman |
| 2025-11-12 12:03:05 | × | deptype_ quits (~deptype@2406:b400:3a:73c2:9a6c:1796:18b4:82bc) (Remote host closed the connection) |
| 2025-11-12 12:03:19 | → | deptype_ joins (~deptype@2406:b400:3a:73c2:98a2:6042:92fc:d969) |
| 2025-11-12 12:10:40 | × | Googulator quits (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-12 12:10:43 | → | Googulator99 joins (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-12 12:22:16 | × | fp quits (~Thunderbi@130.233.70.206) (Remote host closed the connection) |
| 2025-11-12 12:23:07 | × | deptype_ quits (~deptype@2406:b400:3a:73c2:98a2:6042:92fc:d969) (Remote host closed the connection) |
| 2025-11-12 12:23:17 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-11-12 12:23:22 | → | deptype_ joins (~deptype@2406:b400:3a:73c2:5c5a:fd15:b892:dc7c) |
| 2025-11-12 12:23:45 | → | fp joins (~Thunderbi@2001:708:20:1406::1370) |
| 2025-11-12 12:24:48 | × | fp quits (~Thunderbi@2001:708:20:1406::1370) (Client Quit) |
| 2025-11-12 12:25:08 | → | fp joins (~Thunderbi@2001:708:20:1406::1370) |
| 2025-11-12 12:25:42 | → | Googulator26 joins (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-12 12:25:43 | × | Googulator99 quits (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-12 12:28:11 | <kuribas> | tomsmeding: that sounds sensible. Multiple phases are easier than putting everything in a single phase. |
| 2025-11-12 12:28:39 | <tomsmeding> | then exercise: fuse the passes :p |
| 2025-11-12 12:28:45 | <tomsmeding> | (not necessarily a good idea for readability) |
| 2025-11-12 12:29:16 | <kuribas> | tomsmeding: and I think haskell parsing is complicated enough :) |
| 2025-11-12 12:31:39 | × | lucabtz quits (~lucabtz@user/lucabtz) (Ping timeout: 244 seconds) |
| 2025-11-12 12:35:43 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-11-12 12:36:54 | bwe | was told that Haskell being a language great for parsing. |
| 2025-11-12 12:37:47 | → | laxmik joins (~user@pc192b.fzu.cz) |
| 2025-11-12 12:40:42 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-12 12:40:43 | × | Googulator26 quits (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-12 12:40:43 | → | Googulator42 joins (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-12 12:42:27 | <__monty__> | Great for parsing but hard to parse. |
| 2025-11-12 12:42:37 | <__monty__> | At least for computers. |
| 2025-11-12 12:42:48 | <kuribas> | __monty__: not just computers... |
| 2025-11-12 12:43:12 | <kuribas> | Look how many people have difficulty with layout-rule. |
| 2025-11-12 12:43:56 | <__monty__> | It has some difficult nuances but TBH I think it's a bit of a victim of its own success. |
| 2025-11-12 12:44:31 | <__monty__> | It's usually so flexible that when you run into a hard constraint it feels worse. |
| 2025-11-12 12:44:35 | → | lucabtz joins (~lucabtz@user/lucabtz) |
| 2025-11-12 12:45:38 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-11-12 12:47:40 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Ping timeout: 244 seconds) |
| 2025-11-12 12:48:38 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 2025-11-12 12:51:52 | <lucabtz> | do you think writing a pandoc writer could be a good exercise to practice some haskell? |
| 2025-11-12 12:52:33 | <kuribas> | lucabtz: sure |
| 2025-11-12 12:52:36 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-12 12:53:51 | <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 12:59:22 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2025-11-12 12:59:46 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 2025-11-12 13:00:44 | → | Googulator29 joins (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-12 13:00:47 | × | Googulator42 quits (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-12 13:01:46 | × | Lycurgus quits (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 2025-11-12 13:06:24 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-11-12 13:09:37 | → | poscat0x04 joins (~poscat@user/poscat) |
| 2025-11-12 13:11:18 | × | poscat quits (~poscat@user/poscat) (Ping timeout: 256 seconds) |
| 2025-11-12 13:11:36 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2025-11-12 13:23:46 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-11-12 13:28:17 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-12 13:30:50 | → | Googulator46 joins (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) |
| 2025-11-12 13:30:50 | × | Googulator29 quits (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-12 13:31:03 | × | bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-11-12 13:40:51 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-11-12 13:41:00 | × | Googulator46 quits (~Googulato@2a01-036d-0106-0180-8127-ba79-55a7-6f29.pool6.digikabel.hu) (Quit: Client closed) |
All times are in UTC.