Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 703 704 705 706 707 708 709 710 711 712 713 .. 5022
— 502,152 events total
2020-10-17 21:47:43 → ephemera_ joins (~E@122.34.1.187)
2020-10-17 21:47:52 <CodeWeaver> exa: Okay, loaded from file, evaluating foo (), where it behaves right, the type is:
2020-10-17 21:47:53 <CodeWeaver> foo :: Num a => p -> [a]
2020-10-17 21:47:56 <jil> why don't I nee back quote around && ?
2020-10-17 21:48:23 × merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 260 seconds)
2020-10-17 21:48:39 <CodeWeaver> jil: because its an operator. You turn normal functions into operators with the `myadd` syntax, and you turn operators into ordinary functions with the (&&) syntax
2020-10-17 21:49:07 <CodeWeaver> exa: The type for the directly pasted let foo _ = ... line gives:
2020-10-17 21:49:08 <CodeWeaver> foo :: Num a => p -> [a]
2020-10-17 21:49:24 <CodeWeaver> So, nothing explicitly revealed from :t
2020-10-17 21:50:12 <CodeWeaver> Very odd that the dethunking would simply not happen in one case.
2020-10-17 21:50:16 <[exa]> CodeWeaver: o good, try forcing the type to p -> [Int]
2020-10-17 21:50:50 <CodeWeaver> exa: will do.
2020-10-17 21:51:02 × knupfer quits (~Thunderbi@87.123.206.163) (Ping timeout: 258 seconds)
2020-10-17 21:52:15 <[exa]> anyway I think this might be the whole reason for monomorphism restriction; the parameter appears there automagically and there is no way to really memoize something with a parameter
2020-10-17 21:52:37 <CodeWeaver> But I'm not memoizing foo.
2020-10-17 21:52:42 <CodeWeaver> I'm memoizing q, inside foo.
2020-10-17 21:52:46 <jil> Clear. Thank you
2020-10-17 21:53:02 <CodeWeaver> q has no relationship to the 'throwaway value' p.
2020-10-17 21:53:29 <[exa]> CodeWeaver: that might vary if you start pulling the code out of context
2020-10-17 21:53:38 <[exa]> not sure though
2020-10-17 21:54:05 <[exa]> if you specialized the code to Ints and nothing happened, it's likely not the monomorphism restriction
2020-10-17 21:54:31 <CodeWeaver> Nope, no effect. At least if I got my multiline let syntax in the repl right.
2020-10-17 21:55:10 → _ashbreeze_ joins (~mark@72-161-252-32.dyn.centurytel.net)
2020-10-17 21:55:14 <[exa]> quite likely, it's pretty resistant to weirdness :]
2020-10-17 21:55:21 <[exa]> ok nevermind, it was a guess :D
2020-10-17 21:55:25 <CodeWeaver> Good guess.
2020-10-17 21:55:59 <CodeWeaver> Its more a curiosity, because by the time I'm ready to do something performant, I'm rarely doing direct pastes into the repl like that. But.... it really bugs me not to know. ;)
2020-10-17 21:56:23 <CodeWeaver> I mean, I"m literally using the repl in both cases. It's just that in one case it's bein gloaded from a file.
2020-10-17 21:56:25 × ashbreeze quits (~mark@72-161-252-32.dyn.centurytel.net) (Ping timeout: 240 seconds)
2020-10-17 21:56:28 hackage uniqueness-periods-vector-examples 0.13.1.0 - Usage examples for the uniqueness-periods-vector series of packages https://hackage.haskell.org/package/uniqueness-periods-vector-examples-0.13.1.0 (OleksandrZhabenko)
2020-10-17 21:56:40 <dolio> Loaded from a file isn't the same as pasted into the repl.
2020-10-17 21:56:48 <CodeWeaver> Okay, that's a fair statement.
2020-10-17 21:57:15 <CodeWeaver> But I am still not quite sure why the evaluation would be different in that particular way. The reuslt is the same, obviously, but the dethunking is wildly different.
2020-10-17 21:57:56 <dolio> Different defaulting rules are enabled in the repl, so it may be treating the code differently in each case.
2020-10-17 21:58:22 <CodeWeaver> Mm.
2020-10-17 21:58:22 → mirrorbird joins (~psutcliff@2a00:801:42b:7891:16b1:e53f:55b2:15e1)
2020-10-17 21:58:43 <CodeWeaver> I wonder if I can change that default in the repl just for the sake of this test.
2020-10-17 22:00:37 × djellemah quits (~djellemah@2601:5c2:100:96c:e008:b638:39fe:6a54) (Ping timeout: 260 seconds)
2020-10-17 22:01:55 <dolio> I wouldn't trust breaking a whole expression into a bunch of separate lines in the REPL, either.
2020-10-17 22:02:22 <dolio> Things need to be treated differently when they're expected to work line-by-line.
2020-10-17 22:02:25 × rprije quits (~rprije@203-219-208-42.static.tpgi.com.au) (Ping timeout: 240 seconds)
2020-10-17 22:02:36 → rprije joins (~rprije@110-175-117-18.tpgi.com.au)
2020-10-17 22:02:42 <dolio> GHC isn't, like, collecting all the lines you type in, and reconsidering previous ones in light of later ones.
2020-10-17 22:03:27 <CodeWeaver> Sure. But in this case the expression I'm evaluating, the type signature aside, is one line, and the dethunking is on a value expressly inside the function in question. That's a pretty odd difference.
2020-10-17 22:03:45 <[exa]> CodeWeaver: very roughly, if it's about types, you might just put a typehole everywhere and try to find a difference. But chances are it isn't, esp. if reusing the thunk would eg. depend on optimization
2020-10-17 22:03:51 <CodeWeaver> I'm sure there's a reason. Don't get me wrong, I understand the REPL is likely to be a special case... but I'm curious what the special case is on this one.
2020-10-17 22:04:23 × ech quits (~user@gateway/tor-sasl/ech) (Ping timeout: 240 seconds)
2020-10-17 22:04:25 <CodeWeaver> Okay, sure.
2020-10-17 22:04:40 <CodeWeaver> I'll see if I can scare up a plausible reason.
2020-10-17 22:05:09 <dolio> It's not super clear exactly what you're doing in each case, either.
2020-10-17 22:05:13 <[exa]> perhaps just wait for more people showing up here, or repost on monday morning
2020-10-17 22:05:24 × emmanuel_erc quits (~user@2604:2000:1382:ce03:e422:6bdf:36af:752a) (Remote host closed the connection)
2020-10-17 22:05:34 <CodeWeaver> Yup, sure. I won't belabour the point much more today. But I do appreciate the time.
2020-10-17 22:05:37 → emmanuel_erc joins (~user@2604:2000:1382:ce03:c90a:9d9:2f5d:e50)
2020-10-17 22:06:12 × emmanuel_erc quits (~user@2604:2000:1382:ce03:c90a:9d9:2f5d:e50) (Remote host closed the connection)
2020-10-17 22:06:15 <dolio> Because there are a lot of variables. Like, telling GHC to compile a file and then opening it in the REPL is different from not compiling it first, I think.
2020-10-17 22:06:20 → emmanuel_erc joins (~user@2604:2000:1382:ce03:c90a:9d9:2f5d:e50)
2020-10-17 22:06:55 <CodeWeaver> Well, I'm not telling GHC to compile anything at present. This is all pure repl. Just with a :load instead of a paste.
2020-10-17 22:07:02 <CodeWeaver> Which, yes, I realize, is still likely different.
2020-10-17 22:07:44 <CodeWeaver> : guess you could argue it's 'internally compiling' by doing a :load, but that too is beyond my immediate ken.
2020-10-17 22:09:18 <dolio> Well, maybe. I don't know specifically.
2020-10-17 22:10:04 <dolio> I think it compiles it, but it might use different settings than compiling before :load.
2020-10-17 22:10:29 → chris joins (~chris@81.96.113.213)
2020-10-17 22:10:32 <dolio> Also :load is different from import, for instance. :)
2020-10-17 22:10:47 <dolio> And I'm unsure what effects that has besides just scoping.
2020-10-17 22:10:48 <CodeWeaver> Because that doesn't complicate my life. :D
2020-10-17 22:10:52 chris is now known as Guest98505
2020-10-17 22:11:29 → ensyde joins (~ensyde@2600:1702:2e30:1a40:e1f9:6cbb:4eca:3c84)
2020-10-17 22:11:53 × son0p quits (~son0p@181.136.122.143) (Quit: Lost terminal)
2020-10-17 22:11:54 → ech joins (~user@gateway/tor-sasl/ech)
2020-10-17 22:12:03 <CodeWeaver> Reading up on the MR, I can see how this might be the case, but I'd love to be able to prove it somehow, one way or the other.
2020-10-17 22:12:32 <CodeWeaver> Fascinating.
2020-10-17 22:14:45 × ephemera_ quits (~E@122.34.1.187) (Ping timeout: 256 seconds)
2020-10-17 22:15:18 → merijn joins (~merijn@83-160-49-249.ip.xs4all.nl)
2020-10-17 22:15:42 <dolio> MR seems like the most likely answer.
2020-10-17 22:16:26 <CodeWeaver> The more I read about it, the more I agree.
2020-10-17 22:16:42 → ephemera_ joins (~E@122.34.1.187)
2020-10-17 22:17:05 <CodeWeaver> q isn't just a value in this case. It's a function expecting a type dictionary, bound at each of the use sites, and only because its in the repl.
2020-10-17 22:17:09 <CodeWeaver> I _think_.
2020-10-17 22:17:51 <CodeWeaver> Its happening for the same reason I use the phony parameter for foo in the first place -- to avoid caching.
2020-10-17 22:17:56 <CodeWeaver> Again, I _think_.
2020-10-17 22:17:57 <dolio> I think it's off by default in the REPL, yeah.
2020-10-17 22:18:10 → _deepfire joins (~user@80.92.100.69)
2020-10-17 22:18:12 <CodeWeaver> Super fascinating.
2020-10-17 22:18:14 <dolio> Because it's much easier to break things with it line-by-line.
2020-10-17 22:18:32 <dolio> Default to something is invalid for a later line.
2020-10-17 22:18:34 <CodeWeaver> Sure. The fact that it's in one line in my case probably doesn't justify doing it there.
2020-10-17 22:19:39 <dolio> Yeah, it's either on or off. It's not going to do a case-by-case analysis of whether or not to do it.
2020-10-17 22:20:20 <CodeWeaver> I could see that being a WORSE problem for people trying to figure it out, if it _sometimes_ did it. I mean you could have scoped behaviour in an expression, but that'd be super confusing if you didn't know about it.
2020-10-17 22:20:37 <CodeWeaver> Yeah, okay. I;m seeing this now. At least a little.
2020-10-17 22:21:20 <_deepfire> Is the TH's Quote monad primarily about hygienic name allocation?
2020-10-17 22:23:35 <phadej> yes
2020-10-17 22:23:46 <phadej> or in fact, only about that
2020-10-17 22:24:08 <_deepfire> thank you! : -)
2020-10-17 22:24:54 <phadej> (don't mix Quote and Quasi, latter is "everything")
2020-10-17 22:26:26 <CodeWeaver> PROOF (or close enough): Changed expression to: let {q::Integer;q = .... }
2020-10-17 22:26:36 <CodeWeaver> Now behaves like the loaded file. MR almost certainly.
2020-10-17 22:26:58 <CodeWeaver> You all are magnificent. Thanks, exa, dolio.
2020-10-17 22:27:05 → GyroW_ joins (~GyroW@ptr-48ujrfd1ztq5fjywfw3.18120a2.ip6.access.telenet.be)
2020-10-17 22:27:05 × GyroW_ quits (~GyroW@ptr-48ujrfd1ztq5fjywfw3.18120a2.ip6.access.telenet.be) (Changing host)
←Prev  Next→
Page 1 .. 703 704 705 706 707 708 709 710 711 712 713 .. 5022

All times are in UTC.