Logs: liberachat/#haskell
| 2021-08-05 14:19:30 | × | Cajun quits (~Cajun@user/cajun) (Quit: Client closed) |
| 2021-08-05 14:20:03 | → | MidAutumnHotaru joins (~MidAutumn@user/midautumnmoon) |
| 2021-08-05 14:20:48 | <[exa]> | mastarija: it's only looking at the typeclass signature, likely has no idea that it can use the instance |
| 2021-08-05 14:20:59 | <[exa]> | (I'd do same) |
| 2021-08-05 14:21:02 | <mastarija> | :) |
| 2021-08-05 14:21:03 | × | sczar quits (~zed@49.36.176.147) (Read error: Connection reset by peer) |
| 2021-08-05 14:22:43 | <[exa]> | that said, your instance may not be specific enough to actually decide that it's the one that it wants to use |
| 2021-08-05 14:23:07 | <[exa]> | try adding a fundep like `| m v x -> o` |
| 2021-08-05 14:24:12 | <mastarija> | [exa], hm... yes, that works |
| 2021-08-05 14:25:16 | <mastarija> | but it's a problem in case I want to have two same o's for different m v x |
| 2021-08-05 14:25:22 | <mastarija> | Oh well.. |
| 2021-08-05 14:25:40 | <[exa]> | without the fundep, the typesystem needs to assume there might be additional choice of the output (not necessarily a monad, and not necessarily the original monad) |
| 2021-08-05 14:25:41 | <merijn> | mastarija: I recommend reconsidering why this should be a class in the first place :p |
| 2021-08-05 14:26:03 | <mastarija> | merijn, because I want it to be :P |
| 2021-08-05 14:26:17 | × | MidAutumnHotaru quits (~MidAutumn@user/midautumnmoon) (Quit: Leaving for a break - theLounge) |
| 2021-08-05 14:26:48 | <[exa]> | mastarija: that's usually the common source of design problems in programming (much more pronounced with OOP though :D ) |
| 2021-08-05 14:26:49 | → | MidAutumnHotaru joins (~MidAutumn@user/midautumnmoon) |
| 2021-08-05 14:26:52 | × | Guest25 quits (~Guest25@88.123.18.247) (Quit: Client closed) |
| 2021-08-05 14:27:20 | <mastarija> | I want stuff to work my way!!! |
| 2021-08-05 14:27:22 | <[exa]> | mastarija: anyway, the common way is to wrap the 'o' in newtypes and make instances with that |
| 2021-08-05 14:27:39 | <[exa]> | (disambiguates a lot) |
| 2021-08-05 14:27:44 | <merijn> | mastarija: I recommend modifying your way to include code that is less of a hell to maintain :p |
| 2021-08-05 14:27:58 | <mastarija> | Not satisfied with that, I'll have to think some more |
| 2021-08-05 14:28:41 | <merijn> | I mean, without context that example class and type definition looks like the kinda code that makes me go "heh, good luck with that, I'll talk to you in 6 months when you've figured out this was a bad idea the painful way" :p |
| 2021-08-05 14:29:18 | <mastarija> | merijn, that was just a contrived example |
| 2021-08-05 14:29:31 | <mastarija> | I have something much worse for real usecase :D |
| 2021-08-05 14:29:34 | <merijn> | Contrived examples give but feedback to questions :p |
| 2021-08-05 14:29:42 | <merijn> | RIP your sanity 3 months from now |
| 2021-08-05 14:29:44 | <[exa]> | mastarija: anyway, if a function gets `(v -> m x)` and `v`, how elase can it produce the `o` than taking it from a single place from `v`? |
| 2021-08-05 14:30:23 | <mastarija> | It can't, I just created an example where I'm unable to unify the types |
| 2021-08-05 14:30:23 | <[exa]> | (assuming a "normal" monad) |
| 2021-08-05 14:30:33 | <[exa]> | ah ok |
| 2021-08-05 14:30:35 | × | burnside_ quits (~burnsides@dhcp168-019.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2021-08-05 14:30:36 | × | MidAutumnHotaru quits (~MidAutumn@user/midautumnmoon) (Client Quit) |
| 2021-08-05 14:30:48 | <mastarija> | Question is why isn't this unifying, it's not about usefulness or sanity of the class |
| 2021-08-05 14:30:49 | <mastarija> | :D |
| 2021-08-05 14:31:04 | <merijn> | mastarija: Simple answer: Constraints on instances are ignored for selection |
| 2021-08-05 14:31:23 | <merijn> | And "open world assumption" |
| 2021-08-05 14:31:28 | <[exa]> | +1 ^ |
| 2021-08-05 14:32:04 | <merijn> | mastarija: The fact that *currently* there is no other instance is insufficient for GHC to assume such an instance will not exist in the future, hence your choice is ambiguous |
| 2021-08-05 14:32:09 | <mastarija> | What would that mean? That an instance can come in at a later date |
| 2021-08-05 14:32:11 | <mastarija> | Oh.. |
| 2021-08-05 14:32:15 | <merijn> | mastarija: Yes |
| 2021-08-05 14:32:18 | <mastarija> | I guess I was on the right track |
| 2021-08-05 14:32:23 | <[exa]> | mastarija: but it needs to compile at a present date :] |
| 2021-08-05 14:32:31 | <mastarija> | Yes :) |
| 2021-08-05 14:32:57 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-08-05 14:33:20 | × | FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Quit: FinnElija) |
| 2021-08-05 14:33:20 | → | hexfive joins (~eric@50.35.83.177) |
| 2021-08-05 14:33:24 | × | hexfive quits (~eric@50.35.83.177) (Client Quit) |
| 2021-08-05 14:34:00 | → | pbrisbin joins (~patrick@50-196-56-254-static.hfc.comcastbusiness.net) |
| 2021-08-05 14:35:23 | <[exa]> | mastarija: I see you kinda want to decide the computation by what result is expected, in that case I kinda feel the good fundep there might actually be `o -> m` |
| 2021-08-05 14:35:55 | <[exa]> | if you want an IO action out, what else than IO stuff would you get in? |
| 2021-08-05 14:36:05 | <mastarija> | I mean, I already got that working, but I have one final problem. |
| 2021-08-05 14:36:07 | → | MidAutumnHotaru joins (~MidAutumn@user/midautumnmoon) |
| 2021-08-05 14:36:37 | <mastarija> | I have this signature in my class `(v -> x) -> Validator m i e -> Validator m v o` |
| 2021-08-05 14:36:48 | × | waleee quits (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Ping timeout: 256 seconds) |
| 2021-08-05 14:36:57 | <mastarija> | But I so badly want to make an instance like this `(v -> x) -> [Validator m i e] -> Validator m v o` |
| 2021-08-05 14:37:01 | <mastarija> | Alognside the first one |
| 2021-08-05 14:37:07 | → | FinnElija joins (~finn_elij@user/finn-elija/x-0085643) |
| 2021-08-05 14:37:21 | <[exa]> | functors to the rescue! |
| 2021-08-05 14:37:26 | <mastarija> | And if I extract the second argument into the type class, then it doesn't unify e.g. (v -> x) -> stuff -> Validator m v o |
| 2021-08-05 14:37:27 | → | notzmv joins (~zmv@user/notzmv) |
| 2021-08-05 14:37:49 | <mastarija> | [exa], how would that help? |
| 2021-08-05 14:38:06 | <[exa]> | say, `Traversable f => (v->x) -> f (Validator m i e) -> Validator m v o` |
| 2021-08-05 14:38:19 | <[exa]> | which collapses to your original version with Identity |
| 2021-08-05 14:38:43 | <mastarija> | But then I have to wrap my validator in Identity, no? |
| 2021-08-05 14:38:49 | <[exa]> | yes |
| 2021-08-05 14:38:59 | <[exa]> | or in [ ] |
| 2021-08-05 14:39:02 | <mastarija> | Well, that just ain't gonna cut it :D |
| 2021-08-05 14:39:15 | <mastarija> | Ah... I guess I give up. |
| 2021-08-05 14:39:27 | <[exa]> | or just make a simple function like doThing1 which wraps it for you |
| 2021-08-05 14:39:29 | <mastarija> | The first solution is ok. People can just use mconcat |
| 2021-08-05 14:39:53 | <mastarija> | Yes, that's no problem, but I was hoping for a nice overloaded interface :) |
| 2021-08-05 14:39:54 | × | Vajb quits (~Vajb@n2bovg6licdnldblt-2.v6.elisa-mobile.fi) (Read error: Connection reset by peer) |
| 2021-08-05 14:40:13 | <[exa]> | don't overoverload. :D |
| 2021-08-05 14:40:26 | <mastarija> | Ye, I'm stopping now |
| 2021-08-05 14:40:44 | <merijn> | Overloading is the one true way to unhappiness :p |
| 2021-08-05 14:41:10 | <[exa]> | the more the interface is overloaded, the less stuff can be derived automatically, in turn the less happy rainbow magicks you get from the types |
| 2021-08-05 14:41:41 | → | shriekingnoise joins (~shrieking@186.137.144.80) |
| 2021-08-05 14:41:57 | <mastarija> | merijn, I was quite happy with my first version |
| 2021-08-05 14:42:01 | <mastarija> | but then I wanted more |
| 2021-08-05 14:42:11 | <[exa]> | mastarija: btw if you wanted to think about it-- it's sometimes very very very educating to just rewrite the MPTCs to prolog |
| 2021-08-05 14:42:36 | <merijn> | It's very educating to just replace your typeclasses with datatypes/records instead :p |
| 2021-08-05 14:42:59 | → | fef joins (~thedawn@user/thedawn) |
| 2021-08-05 14:43:04 | <mastarija> | Yes, I did stuff like that |
| 2021-08-05 14:43:26 | <mastarija> | then I'd have something like `check simple whatever` |
| 2021-08-05 14:43:33 | <mastarija> | and `check array whatever` |
| 2021-08-05 14:44:35 | <mastarija> | But then again, what's the point of having a nice high level language if you stick to the prolog capabilities |
| 2021-08-05 14:44:45 | <mastarija> | I want more!! |
| 2021-08-05 14:44:46 | <adamCS> | merijn: Yes! Especially the ones that don't have laws or do have laws but are not uniquely implemented on a per-type basis. |
| 2021-08-05 14:45:07 | <merijn> | Replacing typeclasses with records of function is underrated |
| 2021-08-05 14:45:09 | → | Vajb joins (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-08-05 14:45:30 | <[exa]> | (b but but they are records of functions) |
| 2021-08-05 14:45:33 | <merijn> | Typeclass polymorphism, other than perhaps "tagless final"-style decomposition is overrated |
| 2021-08-05 14:46:05 | <adamCS> | Nearly every time I have used typeclasses for convenience it has bitten me and nearly every time I have replaced them with something else I have ended up with something more powerful and nearly as convenient. |
| 2021-08-05 14:46:14 | <merijn> | adamCS: Same |
| 2021-08-05 14:46:23 | → | kuribas joins (~user@ptr-25vy0i9d6q57yj1bhvo.18120a2.ip6.access.telenet.be) |
| 2021-08-05 14:46:41 | <merijn> | adamCS: The only thing that's really grown on me is (application/feature specific) tagless final classes, I'm appreciating those more and more |
| 2021-08-05 14:47:02 | <merijn> | adamCS: But only if you can keep their definition very tiny and implement everything else on top of that |
All times are in UTC.