Logs: freenode/#haskell
| 2021-03-31 16:46:40 | <lambdabot> | • Couldn't match type ‘(Maybe (a0, b1), b2)’ with ‘Maybe b0’ |
| 2021-03-31 16:46:40 | <lambdabot> | arising from a functional dependency between: |
| 2021-03-31 16:46:50 | <kuribas> | > preview (_1 . _Just . _2) (Just (1, 2), 3) |
| 2021-03-31 16:46:51 | <lambdabot> | Just 2 |
| 2021-03-31 16:46:59 | <kuribas> | > view (_1 . _Just . _2) (Just (1, 2), 3) |
| 2021-03-31 16:47:00 | <gaff> | basically, if the function is one module, the call works fine, but if the code is located in another module, it hangs. i am not sure why. |
| 2021-03-31 16:47:01 | <lambdabot> | error: |
| 2021-03-31 16:47:01 | <lambdabot> | • Ambiguous type variable ‘a0’ arising from a use of ‘show_M623296576548... |
| 2021-03-31 16:47:01 | <lambdabot> | prevents the constraint ‘(Show a0)’ from being solved. |
| 2021-03-31 16:47:13 | <kuribas> | > view (_1 . _Just . _2) (Just (1, 2), 3) :: Int |
| 2021-03-31 16:47:15 | <lambdabot> | error: |
| 2021-03-31 16:47:15 | <lambdabot> | • No instance for (Monoid Int) arising from a use of ‘_Just’ |
| 2021-03-31 16:47:15 | <lambdabot> | • In the first argument of ‘(.)’, namely ‘_Just’ |
| 2021-03-31 16:47:22 | × | masterplain quits (ce7fb161@ics177-97.icsincorporated.com) (Changing host) |
| 2021-03-31 16:47:22 | → | masterplain joins (ce7fb161@unaffiliated/sayo-) |
| 2021-03-31 16:47:41 | <kuribas> | fuzzy_id: so that fails, because view tries to collect all the results in a monoid, but the result isn't a monoid. |
| 2021-03-31 16:48:08 | × | dbmikus quits (~dbmikus@cpe-76-167-86-219.natsow.res.rr.com) (Ping timeout: 246 seconds) |
| 2021-03-31 16:48:37 | ← | masterplain parts (ce7fb161@unaffiliated/sayo-) () |
| 2021-03-31 16:48:46 | <kuribas> | fuzzy_id: it's a detail which you may forget :) Just remember that view can only be used if you always return a value. |
| 2021-03-31 16:48:53 | <gaff> | it is quite strange behaviour. |
| 2021-03-31 16:49:33 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-03-31 16:50:37 | <fuzzy_id> | kuribas: ok. that clearifies things a bit. |
| 2021-03-31 16:50:39 | <fuzzy_id> | I guess. |
| 2021-03-31 16:51:29 | <kuribas> | fuzzy_id: preview return (Just x), where x is the first value, or Nothing, when there are no values. |
| 2021-03-31 16:51:36 | × | chele quits (~chele@ip5b40237d.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2021-03-31 16:51:40 | × | nbloomf quits (~nbloomf@2600:1700:ad14:3020:7ca5:80cc:e540:ad18) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-03-31 16:51:52 | → | royal_screwup21 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2021-03-31 16:51:56 | <ski> | gaff : what if you change from using `i' in `Integral', to using `Integer' ? |
| 2021-03-31 16:53:03 | <gaff> | well, i haven't tried that, but how would it affect which module the code lives? |
| 2021-03-31 16:53:22 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-03-31 16:53:24 | <gaff> | also, for smaller inputs, things work just fine. |
| 2021-03-31 16:53:43 | <geekosaur> | gaff, inlining will vary depending on where the code is |
| 2021-03-31 16:53:57 | <geekosaur> | among other things |
| 2021-03-31 16:54:05 | × | cheater quits (~user@unaffiliated/cheater) (Ping timeout: 246 seconds) |
| 2021-03-31 16:54:07 | <geekosaur> | and specialisation |
| 2021-03-31 16:54:12 | <gaff> | i see |
| 2021-03-31 16:54:35 | <gaff> | that's a nasty surprise. |
| 2021-03-31 16:54:39 | <ski> | gaff : it could possibly affect efficiency |
| 2021-03-31 16:54:44 | → | cheater joins (~user@unaffiliated/cheater) |
| 2021-03-31 16:54:54 | × | kuribas quits (~user@ptr-25vy0i8a26pq5ck0xjc.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2021-03-31 16:55:30 | <fuzzy_id> | kuribas: thanks a lot. I guess I just have to sit down and study lenses properly. |
| 2021-03-31 16:55:32 | → | molehillish joins (~molehilli@2600:8800:8d06:1800:49e2:dd02:cb68:846) |
| 2021-03-31 16:55:32 | <ski> | in any case, using a constrained polymorphic `primes' like that is probably not that good, in the first place |
| 2021-03-31 16:56:10 | <ski> | (i guess possibly it floats the instantiation out of the lambda) |
| 2021-03-31 16:56:20 | → | jakalx joins (~jakalx@base.jakalx.net) |
| 2021-03-31 16:58:46 | × | conal quits (~conal@64.71.133.70) (Ping timeout: 240 seconds) |
| 2021-03-31 16:59:59 | × | molehillish quits (~molehilli@2600:8800:8d06:1800:49e2:dd02:cb68:846) (Ping timeout: 245 seconds) |
| 2021-03-31 16:59:59 | <gaff> | ski: that works! i changed it to INT |
| 2021-03-31 17:00:17 | → | conal joins (~conal@64.71.133.70) |
| 2021-03-31 17:00:26 | <ski> | gaff : because, now `primes' is shared |
| 2021-03-31 17:00:29 | → | dbmikus joins (~dbmikus@cpe-76-167-86-219.natsow.res.rr.com) |
| 2021-03-31 17:01:10 | <gaff> | ski: i din't catch you. shared? |
| 2021-03-31 17:01:29 | <ski> | gaff : probably, with `dff', it didn't really hang indefinitely, just took a very long time (possibly exponentially slower), while `df' didn't experience that, due to inlining or specialization or so happening, because it was in the same module |
| 2021-03-31 17:01:51 | <gaff> | ok |
| 2021-03-31 17:02:11 | <gaff> | and why is it working when i change it to INT, as you suggested? |
| 2021-03-31 17:02:25 | <ski> | gaff : with lazy / by-need evaluation, if you do `let x = 2 + 3 in x * x', then the computation of `2 * 3' is shared, so that it's not redone, when the value of the second `x' in `x * x' is demanded |
| 2021-03-31 17:02:50 | <gaff> | correct. |
| 2021-03-31 17:02:59 | → | Neuromancer joins (~Neuromanc@unaffiliated/neuromancer) |
| 2021-03-31 17:03:28 | <ski> | such a memoization/sharing does not happen, if you have a function. if you write `f x = 2 + 3', then `f 4 * f 4' won't share the result of `2 + 3', under by-need |
| 2021-03-31 17:03:54 | <gaff> | i see |
| 2021-03-31 17:04:20 | <ski> | there is no automatic memoization, caching of an association from input values to output values (such a thing would require some kind of equality check on inputs. also there's other possible issues ..) |
| 2021-03-31 17:04:25 | <ski> | however |
| 2021-03-31 17:04:29 | <ski> | if you have |
| 2021-03-31 17:04:45 | <ski> | counting :: Integer i => [i] |
| 2021-03-31 17:04:58 | <ski> | counting = 0 : map (1 +) counting |
| 2021-03-31 17:05:43 | <ski> | even though it *looks* like `counting' would be shared here, it won't. because, under the dictionary-passing translation (/ implementation) of type classes, this will correspond to something like |
| 2021-03-31 17:06:01 | <ski> | counting :: IntegralDict i -> [i] |
| 2021-03-31 17:06:43 | <ski> | counting iDict = fromInteger iDict (0 :: Integer) : map ((+) iDict (fromInteger iDict (1 :: Integer))) (counting iDict) |
| 2021-03-31 17:06:57 | <ski> | (sorry, obviously `Integer i' should have been `Integral i') |
| 2021-03-31 17:07:14 | <gaff> | yeah, i was wondering about that |
| 2021-03-31 17:07:32 | <ski> | where `IntegralDict i' is a data type, a record of implementations of the methods of `Integral' (and superclasses), for `i' |
| 2021-03-31 17:07:44 | <gaff> | i see |
| 2021-03-31 17:07:53 | <ski> | so, "secretly", under this implementation, `counting' will be a function. so, no sharing |
| 2021-03-31 17:08:00 | <ski> | this is the reason for the DMR existing |
| 2021-03-31 17:08:03 | <gaff> | i see |
| 2021-03-31 17:09:35 | <ski> | if you had skipped the type signature on `counting' or `primes', then you'd either gotten an error that it was ambiguous (it refusing to infer it as a *constrained* polymorphic operation), or else it might have picked a default type for `i' (like `Integer'), in case one was available (and then your operation would be monomorphic) |
| 2021-03-31 17:10:06 | <gaff> | okay |
| 2021-03-31 17:10:07 | <ski> | (in this case, i think you'd get the defaulting .. but in general, it might not find a suitable default, and so it would complain) |
| 2021-03-31 17:10:08 | × | zfnmxt quits (~zfnmxt@unaffiliated/zfnmxt) (Quit: Bye!) |
| 2021-03-31 17:10:15 | → | zfnmxt_ joins (~zfnmxt@unaffiliated/zfnmxt) |
| 2021-03-31 17:10:19 | × | Jello_Raptor quits (~Jello_Rap@li641-12.members.linode.com) (Ping timeout: 252 seconds) |
| 2021-03-31 17:10:46 | <gaff> | so in this case, when i cahnge to `INT`, `primes` get shared? |
| 2021-03-31 17:10:53 | × | CitizenSnips quits (~CitizenSn@irc.refl.club) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-03-31 17:10:54 | × | fredcy| quits (fredcy@2600:3c00::f03c:91ff:feae:15ae) (Quit: ZNC - http://znc.in) |
| 2021-03-31 17:11:04 | → | fredcy joins (fredcy@2600:3c00::f03c:91ff:feae:15ae) |
| 2021-03-31 17:11:08 | <gaff> | sorry, *change* |
| 2021-03-31 17:12:20 | → | CitizenSnips joins (~CitizenSn@irc.refl.club) |
| 2021-03-31 17:12:20 | <ski> | (the way to avoid dealing with DMR is to either (a) add an explicit type signature, signalling that you're aware that it's *constrained* polymorphic (so no sharing); or (b), in case it's a function, add explicit parameter to the left of `='. so instead of `f = ...' do `f x = (...) x', or instead of `f = \x -> ..x..', do `f x = ..x..'; or (c) turn off DMR (but then you don't get warned by it, when you lose |
| 2021-03-31 17:12:26 | <ski> | sharing like this)) |
| 2021-03-31 17:12:28 | <ski> | gaff : yes |
| 2021-03-31 17:13:10 | <ski> | if you load the module, then do `take 4 primes', it will show the primes under ten |
| 2021-03-31 17:13:12 | → | Jello_Raptor joins (~Jello_Rap@li641-12.members.linode.com) |
| 2021-03-31 17:13:25 | <gaff> | yes |
| 2021-03-31 17:13:47 | <ski> | if you then do `take 25 primes', it will show the primes under one hundred, but not recompute the first four, sharing them from the previous computation, only recomputing the remaining twentyone |
| 2021-03-31 17:14:14 | <ski> | with `primes' constrained polymorphic, you'll recompute each time. at least under a naïve by-need / lazy implementation |
| 2021-03-31 17:14:17 | → | Forlorn_ joins (~Forlorn@unaffiliated/forlorn) |
| 2021-03-31 17:14:26 | <gaff> | i see |
| 2021-03-31 17:14:41 | <ski> | and then, each call to one of your operations using `primes' would recompute it from the start again, each time it used it |
| 2021-03-31 17:14:49 | <gaff> | correct |
| 2021-03-31 17:15:28 | <ski> | i think even each recursive call might recompute it (unless it does `let'-floating of the specialization to `i') .. and this could likely cause exponential worsening of time |
All times are in UTC.