Logs: liberachat/#haskell
| 2021-06-09 11:27:16 | × | zelmac quits (~quassel@82-69-3-58.dsl.in-addr.zen.co.uk) (Quit: zelmac) |
| 2021-06-09 11:27:17 | × | chddr quits (~Thunderbi@31.148.23.125) (Ping timeout: 268 seconds) |
| 2021-06-09 11:27:25 | <dminuoso> | (This is compact and eloquent, and will use sharing) |
| 2021-06-09 11:28:55 | <Taneb> | merijn: https://gist.github.com/Taneb/e17d338384a62297002983e123d8d59d |
| 2021-06-09 11:29:01 | <dminuoso> | mfix is far more interesting than fix I think |
| 2021-06-09 11:29:27 | <dminuoso> | fix is just handy, but mfix can do things that take a lot more effort than without |
| 2021-06-09 11:29:57 | <Taneb> | merijn: I don't think it's possible to write "size" there with fix and a non-recursive function |
| 2021-06-09 11:29:57 | <tomsmeding> | maerwald: out of context reply, but re the semicolon issue on the last line with rust: it's not going to typecheck when you make the wrong decision in at most one place, I think |
| 2021-06-09 11:30:03 | <Taneb> | Happy to be proven wrong here |
| 2021-06-09 11:30:27 | <maerwald> | tomsmeding: it hinders reading flow |
| 2021-06-09 11:30:31 | <tomsmeding> | not sure if it's possible to conceive a situation where getting two semicolons wrong makes a type correct program again |
| 2021-06-09 11:30:45 | <merijn> | Taneb: hmm, maybe |
| 2021-06-09 11:31:02 | <tomsmeding> | agree about the incongruity with the rest of the imperative language though; go full let...in or have a return keyword |
| 2021-06-09 11:31:07 | <merijn> | Taneb: You're probably right, but I'm too tired to dedicate any brain cycles too considering a way around it :p |
| 2021-06-09 11:31:08 | <hpc> | DigitalKiwi: since it hasn't been mentioned yet, the easiest way to understand fix is that fix (\f -> expression that mentions f) is analogous to f = expression that mentions f |
| 2021-06-09 11:31:27 | <merijn> | hpc: I already did that via my map implementation above ;) |
| 2021-06-09 11:31:34 | <dminuoso> | hpc: modulo knot tying! |
| 2021-06-09 11:31:39 | <Taneb> | merijn: I believe this kind of recursion is invalid in ML, incidentally, but Haskell accepts it without complaint |
| 2021-06-09 11:31:52 | → | pavonia joins (~user@user/siracusa) |
| 2021-06-09 11:31:56 | <dminuoso> | Which I think should still be mentioned. If you naively write `f = expression that mentions f` your stack will suffer |
| 2021-06-09 11:32:07 | <dminuoso> | With fix it wouldnt |
| 2021-06-09 11:33:12 | <merijn> | dminuoso: huh? |
| 2021-06-09 11:33:14 | <merijn> | dminuoso: Why? |
| 2021-06-09 11:33:26 | → | hmmmas joins (~chenqisu1@183.217.201.236) |
| 2021-06-09 11:33:41 | <dminuoso> | mmm |
| 2021-06-09 11:33:47 | <dminuoso> | ah I guess it wouldnt |
| 2021-06-09 11:33:51 | <tomsmeding> | @src fix |
| 2021-06-09 11:33:51 | <lambdabot> | fix f = let x = f x in x |
| 2021-06-09 11:34:32 | × | nschoe quits (~quassel@178.251.84.79) (Ping timeout: 264 seconds) |
| 2021-06-09 11:35:20 | <tomsmeding> | looks like it would be exactly the same, to me |
| 2021-06-09 11:35:32 | → | koishi_ joins (~koishi_@67.209.186.120.16clouds.com) |
| 2021-06-09 11:35:34 | <dminuoso> | Yeah, I think I misremembered something. |
| 2021-06-09 11:35:41 | <dminuoso> | @src cycle |
| 2021-06-09 11:35:41 | <lambdabot> | cycle [] = undefined |
| 2021-06-09 11:35:41 | <lambdabot> | cycle xs = xs' where xs' = xs ++ xs' |
| 2021-06-09 11:35:44 | × | fabfianda quits (~fabfianda@mob-5-90-253-108.net.vodafone.it) (Ping timeout: 250 seconds) |
| 2021-06-09 11:35:52 | <dminuoso> | Maybe my brain was wired wrong with this in mind |
| 2021-06-09 11:36:00 | → | fabfianda joins (~fabfianda@net-93-148-121-206.cust.vodafonedsl.it) |
| 2021-06-09 11:36:30 | <merijn> | yeah |
| 2021-06-09 11:36:39 | × | koishi_ quits (~koishi_@67.209.186.120.16clouds.com) (Remote host closed the connection) |
| 2021-06-09 11:36:42 | <merijn> | "cycle xs = xs ++ cycle xs" is where you'd lose sharing |
| 2021-06-09 11:36:58 | <tomsmeding> | ooooo right sharing |
| 2021-06-09 11:37:38 | × | benin03 quits (~benin@183.82.206.233) (Ping timeout: 244 seconds) |
| 2021-06-09 11:41:14 | <merijn> | but the problem here is the sharing of the *result* of the recursion, rather than the function itself |
| 2021-06-09 11:43:32 | <dminuoso> | That makes sense |
| 2021-06-09 11:43:58 | × | agumonke` quits (~user@88.160.31.174) (Ping timeout: 250 seconds) |
| 2021-06-09 11:44:01 | → | boxscape joins (~boxscape@user/boxscape) |
| 2021-06-09 11:49:53 | × | kenran quits (~kenran@200116b82b683c006ea54bdc3ffd5a0f.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2021-06-09 11:50:42 | × | curiousgay quits (~quassel@178.217.208.8) (Ping timeout: 264 seconds) |
| 2021-06-09 11:52:39 | → | machinedgod joins (~machinedg@135-23-192-217.cpe.pppoe.ca) |
| 2021-06-09 11:53:08 | × | Natch quits (~natch@c-e070e255.014-297-73746f25.bbcust.telenor.se) (Ping timeout: 264 seconds) |
| 2021-06-09 11:54:25 | <DigitalKiwi> | what is sharing |
| 2021-06-09 11:54:59 | → | Natch joins (~natch@c-e070e255.014-297-73746f25.bbcust.telenor.se) |
| 2021-06-09 11:56:00 | → | um joins (niahifz5l1@user/um) |
| 2021-06-09 11:56:10 | ← | um parts (niahifz5l1@user/um) () |
| 2021-06-09 11:56:43 | × | hmmmas quits (~chenqisu1@183.217.201.236) (Quit: Leaving.) |
| 2021-06-09 11:56:59 | <tomsmeding> | let x = complicated_stuff in x + x |
| 2021-06-09 11:57:12 | <tomsmeding> | will only compute x once, because its result is _shared_ between its usages |
| 2021-06-09 11:57:30 | × | ubert quits (~Thunderbi@2a02:8109:9880:303c:ca5b:76ff:fe29:f233) (Ping timeout: 268 seconds) |
| 2021-06-09 11:57:38 | <tomsmeding> | let l = 1 : l in ... |
| 2021-06-09 11:57:52 | <tomsmeding> | there the list and its tail are shared (i.e. point to the same thing in memory) |
| 2021-06-09 11:57:59 | <dminuoso> | This is something you can only get with purity in the language. With an impure language, you demand the compiler prove this is a legit transformation., |
| 2021-06-09 11:58:34 | <dminuoso> | This might be a good teaser why unsafePerformIO can behave really unexpected, because GHC will make assumptions like the above. |
| 2021-06-09 11:59:03 | <dminuoso> | % cycle [1,2,3] |
| 2021-06-09 11:59:09 | <yahb> | dminuoso: [1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2 |
| 2021-06-09 11:59:12 | <boxscape> | dminuoso when you say "This", do you mean having the compiler automatically introduce sharing into an expression that wouldn't otherwise have it? |
| 2021-06-09 11:59:59 | → | lavaman joins (~lavaman@98.38.249.169) |
| 2021-06-09 12:00:01 | → | renzhi joins (~xp@2607:fa49:6500:bc00::e7b) |
| 2021-06-09 12:01:00 | <dminuoso> | boxscape: fsvo of "automatically", anyhow |
| 2021-06-09 12:01:06 | <boxscape> | ok |
| 2021-06-09 12:01:18 | × | pagnol quits (~user@014198154145.ctinets.com) (Ping timeout: 250 seconds) |
| 2021-06-09 12:01:52 | → | andreypopp joins (~andreypop@94.188.42.16) |
| 2021-06-09 12:02:57 | <merijn> | boxscape: CSE (Common Sub-expression Elimination) is an optimisation that exists in GHC, yes |
| 2021-06-09 12:03:09 | <boxscape> | right, okay |
| 2021-06-09 12:03:36 | <merijn> | boxscape: So if you write "(2 + 2) * (2 + 2)" ghc may decide to compile it as "let x = 2 + 2 in x * x" |
| 2021-06-09 12:03:59 | <boxscape> | I remember when I first read (I think in LYAH) that being lazy means every expression is evaluated at most once, I assumed that means CSE is applied to everything |
| 2021-06-09 12:04:21 | <boxscape> | (which of course was not at all what was meant by it) |
| 2021-06-09 12:04:32 | × | lavaman quits (~lavaman@98.38.249.169) (Ping timeout: 264 seconds) |
| 2021-06-09 12:04:42 | <merijn> | boxscape: Well, that also gets is in the pedantic argument that Haskell is "non-strict" and *not* lazy ;) |
| 2021-06-09 12:04:51 | <boxscape> | yes, but I don't think LYAH made that distinction |
| 2021-06-09 12:04:57 | <merijn> | Probably not, no |
| 2021-06-09 12:05:12 | → | nsilv joins (~nsilv@212.103.198.210) |
| 2021-06-09 12:06:21 | × | Kaiepi quits (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection) |
| 2021-06-09 12:06:52 | → | Kaiepi joins (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) |
| 2021-06-09 12:07:40 | → | jmcarthur joins (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) |
| 2021-06-09 12:09:12 | <boxscape> | (looking at google though, it doesn't seem as though the phrase "at most once" appears in LYAH, actually. It does appear in that context in a few other places) |
| 2021-06-09 12:10:53 | × | jmcarthur quits (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) (Client Quit) |
| 2021-06-09 12:11:22 | × | V quits (~v@anomalous.eu) (Quit: We're here. We're queer. Connection reset by peer) |
| 2021-06-09 12:11:55 | → | V joins (~v@anomalous.eu) |
| 2021-06-09 12:13:16 | ← | andreypopp parts (~andreypop@94.188.42.16) (Textual IRC Client: www.textualapp.com) |
| 2021-06-09 12:14:33 | <boxscape> | LYAH does seem to say on the first page though that laziness implies fusion of list operations |
| 2021-06-09 12:16:31 | → | curiousgay joins (~quassel@178.217.208.8) |
| 2021-06-09 12:17:25 | <boxscape> | also in another chapter: "Thanks to Haskell's laziness, even if you map something over a list several times and filter it several times, it will only pass over the list once." http://learnyouahaskell.com/higher-order-functions |
| 2021-06-09 12:17:30 | <boxscape> | which strikes me as wrong |
| 2021-06-09 12:17:33 | <int-e> | boxscape: not really... laziness means that doubleMe(doubleMe(doubleMe(xs))) is evaluated without ever fully evaluating the intermediate lists |
| 2021-06-09 12:18:12 | <int-e> | boxscape: fusion is about completely eliminating the intermediate lists; they don't even exist as a cons with unevaluated tail anymore |
| 2021-06-09 12:18:38 | <boxscape> | int-e yes, I'd agree with that, I think the text is ignoring that fusion is necessary at all though |
| 2021-06-09 12:19:01 | → | delYsid joins (~user@84-115-55-45.cable.dynamic.surfer.at) |
| 2021-06-09 12:19:16 | <int-e> | maybe |
| 2021-06-09 12:19:51 | <boxscape> | (or rather, implying that you get fusion for free as soon as you have laziness) |
All times are in UTC.