Newest at the top
| 2025-02-12 22:56:30 +0100 | <monochrom> | Or worse, you chose the wrong fmap definition, then you rationalized it by misinterpreting the rest of the expression. |
| 2025-02-12 22:56:13 +0100 | <euouae> | justsomeguy: try this instead: `fmap (+1) 2` first |
| 2025-02-12 22:56:12 +0100 | <tomsmeding> | so the "quotes" is indeed accurate, it seems |
| 2025-02-12 22:56:02 +0100 | <tomsmeding> | euouae: experimentally, --ghc-options parses " but passes ' on unchanged |
| 2025-02-12 22:55:33 +0100 | <tomsmeding> | justsomeguy: the order shouldn't matter, which fmap resolves to which definition is determined solely by the types |
| 2025-02-12 22:55:24 +0100 | <monochrom> | You were using the wrong fmap definition. |
| 2025-02-12 22:54:54 +0100 | <justsomeguy> | I'm still confused. Maybe I way trying to apply the outer fmap first, instead of the inner fmap? Figuring out where I went wrong is going to bother me for a while. |
| 2025-02-12 22:54:13 +0100 | <euouae> | tomsmeding: I would say the rest is good, just hold off on the -options variant until more clarification is available |
| 2025-02-12 22:53:31 +0100 | <euouae> | like -W arguments and -f |
| 2025-02-12 22:53:25 +0100 | <euouae> | I guess, realistically, it only gets passed stuff without spaces? |
| 2025-02-12 22:53:23 +0100 | <tomsmeding> | merijn: ? :p |
| 2025-02-12 22:53:09 +0100 | <euouae> | oh... that's not good |
| 2025-02-12 22:52:44 +0100 | <tomsmeding> | --repl-options doesn't even seem to accept " |
| 2025-02-12 22:52:27 +0100 | <euouae> | good catch on C:\Program Files\ typo heh |
| 2025-02-12 22:51:38 +0100 | <tomsmeding> | euouae: good question! |
| 2025-02-12 22:51:14 +0100 | <euouae> | I like how you commented the single option. I agree it's easier to understand now. |
| 2025-02-12 22:50:47 +0100 | Spawns_Carpeting | (~mobile@user/spawns-carpeting/x-6969421) Spawns_Carpeting |
| 2025-02-12 22:50:21 +0100 | <euouae> | tomsmeding: this is dumb, but do 'quotes' also prevent splitting? |
| 2025-02-12 22:50:15 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-02-12 22:49:40 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) (Remote host closed the connection) |
| 2025-02-12 22:49:05 +0100 | <tomsmeding> | merijn: euouae: https://github.com/tomsmeding/cabal/commit/e1faaf097cb8e78a5736f176e5e9542396d278e2 what do you think? |
| 2025-02-12 22:49:04 +0100 | Spawns_Carpeting | (~mobile@user/spawns-carpeting/x-6969421) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-02-12 22:45:56 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-12 22:42:36 +0100 | <tomsmeding> | something like `map`, which polymorphic but not a typeclass method, can be rewritten as-is |
| 2025-02-12 22:42:19 +0100 | tnt2 | tnt1 |
| 2025-02-12 22:42:19 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 260 seconds) |
| 2025-02-12 22:42:09 +0100 | <EvanR> | the definition depends crucially on the type |
| 2025-02-12 22:42:01 +0100 | <EvanR> | justsomeguy, only in the case of typeclass "methods" like fmap |
| 2025-02-12 22:41:29 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-12 22:41:01 +0100 | <justsomeguy> | I think I got so into the habit of just plugging in definitions when evaluating by hand, that I forgot that I have to do type resolution during each step. Most of what I was desk-checking before was monomorphic. |
| 2025-02-12 22:40:49 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-02-12 22:40:12 +0100 | <haskellbridge> | <magic_rb> but ignoring optparse, i actually need this in tomland |
| 2025-02-12 22:39:44 +0100 | <haskellbridge> | <magic_rb> but with optparse-applicative i couldnt get it to work because i couldnt put the different alternatives in subparsers, only commands and optparse wouldnt backtrack through <|> just by itself |
| 2025-02-12 22:39:24 +0100 | michalz | (~michalz@185.246.207.203) (Remote host closed the connection) |
| 2025-02-12 22:39:09 +0100 | <merijn> | you just need to have a (static) parser for the tag inside the subparser |
| 2025-02-12 22:39:04 +0100 | <haskellbridge> | <magic_rb> merijn: i think it can work if you rely on failure and backtracking |
| 2025-02-12 22:38:51 +0100 | <EvanR> | merijn, yeah this is how I expected it |
| 2025-02-12 22:38:51 +0100 | <merijn> | I think it can work, though |
| 2025-02-12 22:38:40 +0100 | <tomsmeding> | that handles "tagged unions" somehow |
| 2025-02-12 22:38:36 +0100 | remedan_ | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-12 22:38:35 +0100 | <tomsmeding> | this would need to be a primitive parser |
| 2025-02-12 22:38:30 +0100 | <haskellbridge> | <magic_rb> yeah... |
| 2025-02-12 22:38:22 +0100 | <tomsmeding> | that's monadic |
| 2025-02-12 22:38:21 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Ping timeout: 252 seconds) |
| 2025-02-12 22:38:14 +0100 | <tomsmeding> | magic_rb: that sounds plausible, you want parsing to depend on the result of some other part of the parser |
| 2025-02-12 22:37:47 +0100 | <merijn> | Scala is surprisingly ok as functional language, but implicits are the bane of my existence >.> |
| 2025-02-12 22:37:06 +0100 | <merijn> | EvanR: Having to debug implicits in scala :p |
| 2025-02-12 22:37:03 +0100 | <EvanR> | because I've been noticing the same thing |
| 2025-02-12 22:37:03 +0100 | <tomsmeding> | merijn: in the .rst docs, can I refer to an option documented in a different file? |
| 2025-02-12 22:36:52 +0100 | <EvanR> | merijn, what's this in relation to |