Newest at the top
| 2025-06-20 12:26:08 +0200 | <haskellbridge> | <Profpatsch> It’s like a holy grail that was just lying on the floor in the corner somewhere |
| 2025-06-20 12:25:40 +0200 | <haskellbridge> | <Profpatsch> I haven’t seen it before |
| 2025-06-20 12:25:34 +0200 | <haskellbridge> | <Profpatsch> I think I’m also, like, the first person to find a dual to "do" notation for Divide? |
| 2025-06-20 12:25:14 +0200 | <tomsmeding> | if that works for you, then that's a solution too, indeed |
| 2025-06-20 12:24:52 +0200 | <haskellbridge> | <Profpatsch> I added an _ to coerce it to a function and now it works |
| 2025-06-20 12:24:34 +0200 | <haskellbridge> | <Profpatsch> tomsmeding: takk for explanation |
| 2025-06-20 12:24:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-06-20 12:23:51 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-06-20 12:22:09 +0200 | <tomsmeding> | *stowed |
| 2025-06-20 12:22:01 +0200 | <tomsmeding> | and without having to disable the monomorphism restriction, which is a rather big hammer that you'd like to leave sowed away if possible |
| 2025-06-20 12:21:39 +0200 | <tomsmeding> | that will cause GHC to infer the polymorphic type, without you having to write out the constraints |
| 2025-06-20 12:21:22 +0200 | <tomsmeding> | Profpatsch: here is an alternative: write `baz :: _ => Build r` and enable -XPartialTypeSignatures, and perhaps set -Wno-partial-type-signatures |
| 2025-06-20 12:19:59 +0200 | <tomsmeding> | because this can be a very unexpected and undesirable introduction of recomputation (and hence slowness), GHC refuses to do this by default |
| 2025-06-20 12:19:33 +0200 | <tomsmeding> | a non-function has the interesting property that once evaluated, it will not be evaluated again; when it's a (polymorphic) function, every use will implicitly apply it to its type class dictionaries, and hence it will be recomputed at every use site |
| 2025-06-20 12:18:53 +0200 | <tomsmeding> | because those constraints become actual arguments at runtime (dictionary translation), and hence for a non-function, that generalisation process would _make it a function_ |
| 2025-06-20 12:18:24 +0200 | <tomsmeding> | if the monomorphism restriction is enabled, GHC will only do this final generalisation process for things that are already functions, i.e. have >=1 argument |
| 2025-06-20 12:18:10 +0200 | trickard_ | (~trickard@cpe-60-98-47-163.wireline.com.au) |
| 2025-06-20 12:17:52 +0200 | <tomsmeding> | any constraints that existed on them become constraints on the function |
| 2025-06-20 12:17:43 +0200 | trickard_ | (~trickard@cpe-60-98-47-163.wireline.com.au) (Ping timeout: 244 seconds) |
| 2025-06-20 12:17:35 +0200 | <tomsmeding> | then, if a function definition without a type signature still has unknown unification variables, they are implicitly "generalised" by introducing a forall quantifier for them |
| 2025-06-20 12:16:53 +0200 | <tomsmeding> | Profpatch: "because it follows directly from the definition of divide2" -- no, how the type inference algorithm works is it first instantiates all forall quantifiers with unknown type variables ("unification variables"), collects all constraints arising from your program and instantiates type variables in order to satisfy the constraints, and then looks at the result |
| 2025-06-20 12:16:40 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-06-20 12:14:53 +0200 | <tomsmeding> | doesn't sound relevant here |
| 2025-06-20 12:14:42 +0200 | <tomsmeding> | defaulting is for guessing an instantiation for an ambiguous type variable based on the type class constraints on that variable |
| 2025-06-20 12:14:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-06-20 12:14:17 +0200 | <haskellbridge> | <Profpatsch> Things are looking bright for contravariant syntax |
| 2025-06-20 12:13:47 +0200 | <haskellbridge> | <Profpatsch> bar :: (HasField "foo" a Text, HasField "bar" a Natural) => p -> TextBuilder a |
| 2025-06-20 12:13:47 +0200 | <haskellbridge> | <Profpatsch> bar _ = field #foo textT <> "foo" <> (field #bar naturalDecimalT) |
| 2025-06-20 12:13:41 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-06-20 12:13:28 +0200 | <haskellbridge> | <Profpatsch> field LabelPrx a = getField @l >$< a |
| 2025-06-20 12:13:28 +0200 | <haskellbridge> | <Profpatsch> field :: forall f l a b. (Contravariant f, HasField l a b) => LabelPrx l -> f b -> f a |
| 2025-06-20 12:12:46 +0200 | <ames> | but like is there an actual problem here? if you turn off the monomorphism restriction or just add a dummy argument to baz ghc infers exactly the type you want (± the dummy argument, i guess) |
| 2025-06-20 12:09:09 +0200 | <ames> | i don't know really how defaulting works and i don't want to find out either i consider it a misfeature |
| 2025-06-20 12:05:59 +0200 | <haskellbridge> | <Profpatsch> No I guess that’s only if I control the type class |
| 2025-06-20 12:05:12 +0200 | <haskellbridge> | <Profpatsch> ames: Can I specify a type defaulting rule for this function? |
| 2025-06-20 12:02:39 +0200 | <ames> | https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/monomorphism.html |
| 2025-06-20 12:01:47 +0200 | <haskellbridge> | <Profpatsch> It does work |
| 2025-06-20 12:01:40 +0200 | <haskellbridge> | <Profpatsch> ames: ohh! if I reformulate as baz bar = divide2 #foo stringT #bar bar |
| 2025-06-20 12:00:16 +0200 | <ames> | baz |
| 2025-06-20 12:00:00 +0200 | <haskellbridge> | <Profpatsch> what’s not a function? |
| 2025-06-20 11:59:47 +0200 | <ames> | well the problem is exactly that it's not a function and ghc does not want to make it one by quantifying over your HasField(s) |
| 2025-06-20 11:59:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-06-20 11:58:58 +0200 | <haskellbridge> | <Profpatsch> cause it should follow directly from the definition of divide2 |
| 2025-06-20 11:58:41 +0200 | <haskellbridge> | <Profpatsch> ames: But then again, ideally HLS could infer the function signature nonetheless |
| 2025-06-20 11:58:03 +0200 | <haskellbridge> | <Profpatsch> I want to make use of Divisible contravariants ergonomic, but without too much overloading going on; I guess if I just use it somewhere in code it should be fine |
| 2025-06-20 11:57:54 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-06-20 11:57:14 +0200 | <haskellbridge> | <Profpatsch> ames: Oh you mean cause GHC needs to infer monomorphic types for toplevel |
| 2025-06-20 11:56:21 +0200 | <ames> | this is just a monomorphism restriction thing |
| 2025-06-20 11:53:57 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-06-20 11:53:15 +0200 | <haskellbridge> | <Profpatsch> I feel like it should be possible in principle |