<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 _2_4 25  
26 27 28 29 30 31
00:02 takle joined
00:05 takle_ joined
00:09 fhoffmeyer joined
00:10 takle_ joined
00:14 shayan_ joined
00:19 handlex joined
00:28 exferenceBot joined
00:29 louispan joined
00:32 mikeyhew_ joined
00:36 <mikeyhew_> Can someone explain to me the errors I'm getting here? http://lpaste.net/353280
00:36 <Cale> mikeyhew_: Did you get that link right, or forget to paste the errors as well?
00:37 <Cale> ah, I see, there are errors in that code.
00:38 yfeldblum joined
00:38 <mikeyhew_> I can paste them in
00:39 mizu_no_oto_work joined
00:40 <mikeyhew_> The first error is "Couldn't match type ‘Church’ with ‘(a2 -> a2) -> a2 -> a2’"... which is weird, because Church = forall a. (a->a)->a->a
00:41 <Cale> Well, that suggests that there's a need to generalise the type of the thing in question: its type lacks the forall quantifier that it needs.
00:42 <mikeyhew_> hmm...
00:42 <Cale> If a2 were some specific type such as Integer, then it wouldn't match because in order to have type Church, the function must work for all types a.
00:44 <mikeyhew_> Which function needs to be polymorphic?
00:44 <Cale> Something of type Church is required to be polymorphic, just because of the forall which is involved.
00:48 <Cale> Ah, okay, so I managed to make it work by introducing some newtypes
00:49 <Cale> http://lpaste.net/353280#a353282
00:50 <Cale> There might be a way to make the original program typecheck by adding an explicit polymorphic type signature somewhere
00:50 <Cale> (I suspect there is)
00:51 <mikeyhew_> What difference does newtype make here?
00:53 <monochrom> An impredicative type system would have be happy with it. But GHC is not impredicative. But newtype can be used to waive the impredicative requirement.
00:54 <Cale> Yeah, I'm trying to work out precisely how it matters in this example, it's a bit tricky, but it comes down to impredicativity -- you end up wanting to instantiate some type variable that was introduced implicitly by the compiler for a subexpression to a polymorphic type
00:55 <Cale> I think it's n mvladd1 in particular which ends up being less polymorphic than it ought to be.
00:56 <Cale> GHC will never instantiate a type variable with a polymorphic type on its own, you have to tell it to do so everywhere that it happens.
00:57 <mikeyhew_> hmmm... OK, I'm reading wikipedia for impredicativity now
00:58 eacameron joined
00:58 <Cale> But basically, you can't treat Haskell as if it's the untyped lambda calculus and have everything work easily.
01:00 <mikeyhew_> Haha yeah. This isn't the most practical of problems
01:00 conal joined
01:01 <glguy> mikeyhew_: The short version is that you can't instantiate a type variable to a polymorphic type
01:01 <glguy> so something like: lCons :: a -> b -> LPair a b
01:02 <glguy> you can't pick a or b to be LPair A B, for example
01:03 <glguy> So the following simpler case isn't going to work:
01:04 <glguy> lCons' :: a -> LPair b c -> LPair a (LPair b c); lCons' = lCons
01:04 Levex joined
01:05 <Cale> Well, instantiating it with LPair A B should be okay
01:05 <glguy> type LPair a b = forall c. (a -> b -> c) -> c
01:05 <glguy> It's hiding a forall
01:05 <Cale> oh, right, it is :)
01:06 <Cale> The more relevant example is Church itself of course, since that also hides a forall
01:08 <glguy> Sure, so that means this doesn't work, either: lCons' :: Church -> b -> LPair Church b; lCons' = lCons
01:08 <mikeyhew_> GHC apparently has an ImpredicativeTypes extension, but it's "extremely flaky" https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#impredicative-polymorphism
01:09 <glguy> It's unmaintained. I don't know why they leave the flag in there
01:09 <geekosaur> yes, and going away in favor of visible type application beefed up a touch
01:09 <monochrom> It has not been fully implemented. In fact it has become more and more unimplemented in favour of other type features.
01:09 NoCreativity joined
01:09 <geekosaur> its basically there because package authors scream whenever someone tries to cut it. which they've been trying to do for years
01:09 fhoffmeyer joined
01:10 <geekosaur> I don;t know if 8.2 will actually cut it, but it will be on life support on that point
01:12 patbecich joined
01:13 <mikeyhew_> Would visible type application make sense for this case?
01:14 <Cale> Not especially, as it'd be ugly as sin
01:14 <geekosaur> it should be able to replace any usage; the main point of ImpredicativeTypes is that something like (.) will never be inferred at a polymorphic type... but you can *annotate* it at a polytype with @
01:14 <Cale> Certainly much worse than just using the newtype
01:15 <geekosaur> but yes, it;d likely be ugly. otoh you can never be quite certain what any ghc version will do with a polytype when ImpredicativeTypes is enabled
01:15 <Cale> Right (but I wasn't suggesting turning on ImpredicativeTypes either)
01:16 xektor joined
01:16 <Cale> Just the usual polymorphic newtype trick works here, and it's arguable that it even makes the code easier for humans to understand as well.
01:16 <Cale> (at least, I find it easier with the newtype in place)
01:20 <Cale> On a tangential note, I wish there weren't such strongly competing goals for which order the arguments to a Church numeral should go in. On the one hand, Church's convention makes numerals endomorphisms, but on the other hand, your "succ" argument comes before the "zero", which is just weird. :)
01:21 patbecich joined
01:22 conal joined
01:22 <monochrom> (a->a) -> (a->a) has a nice ring to it. :)
01:22 <Cale> Then again, maybe that means zero was the first thing to be abstracted over
01:23 <Cale> and succ is on the outside because it was abstracted "after" :)
01:24 cschneid_ joined
01:24 <monochrom> I actually have a cunning plan. "forall a. a -> (a->a) -> a" is equivalent to "forall a. Maybe a -> a". And Maybe has a System F forall equivalent, too...
01:25 cschnei__ joined
01:26 <Cale> Wait, what is the equivalence?
01:26 <Cale> oh, I see
01:26 eacameron joined
01:26 <Cale> er, no
01:27 <Cale> It's forall a. (Maybe a -> a) -> a, isn't it?
01:27 <monochrom> Ah yes.
01:31 Youmu joined
01:40 skeet70 joined
01:43 <mikeyhew_> Thanks for the help, Cale et al. Signing off now
01:43 hexagoxel joined
01:43 mikeyhew_ left
01:44 cschneid_ joined
01:46 Silentnoize joined
01:50 texasmynsted joined
01:58 Levex joined
02:05 patbecich joined
02:07 yfeldblum joined
02:08 flurp joined
02:10 takle joined
02:11 fhoffmeyer joined
02:17 takle joined
02:34 <mniip> oooh
02:35 <mniip> monochrom, I think what you're looking for is
02:36 <mniip> End hom(hom(a, a), hom(a, a)) \cong End hom(hom(a*, a), a)
02:37 conal joined
02:38 <mniip> 1488849650 [04:20:50] <Cale> ... but on the other hand, your "succ" argument comes before the "zero", which is just weird. :)
02:38 <mniip> it just happens that our notation for before->after and codomain->domain has the same direction
02:40 takle joined
02:41 hphuoc25 joined
02:42 hphuoc25 joined
02:43 hphuoc25 joined
03:03 takle joined
03:08 yfeldblum joined
03:13 fhoffmeyer joined
03:18 cschneid_ joined
03:22 takle joined
03:23 \Mike joined
03:36 takle joined
03:43 takle joined
03:47 nocookies92 joined
03:54 takle joined
03:58 louispan joined
03:58 exferenceBot joined
04:00 HEGX64 joined
04:02 Kongaloosh joined
04:02 lspitzner joined
04:03 hexagoxel joined
04:06 takle joined
04:07 hphuoc25 joined
04:09 yfeldblum joined
04:13 fhoffmeyer joined
04:18 takle joined
04:20 hphuoc25 joined
04:22 hphuoc25 joined
04:22 hphuoc25 joined
04:30 louispan joined
04:35 takle joined
04:44 takle joined
04:50 MickyOwly joined
04:50 <MickyOwly> Hey all.. i'm a programmer looking for an unofficial online job.. I have knowledge in Java, Pythom, JS, Web/Mobile.. any suggestions?
05:10 yfeldblum joined
05:11 takle joined
05:15 fhoffmeyer joined
05:18 takle joined
05:28 dni- joined
05:30 nomotif joined
05:33 emmanuel_erc joined
05:36 takle joined
05:38 hexagoxel joined
05:39 begriffs joined
05:42 cschneid_ joined
05:48 Cale joined
05:52 cur8or joined
05:52 louispan joined
05:56 <benzrf> MickyOwly: this isn't really the place to ask about that...
06:02 hexagoxel joined
06:04 takle joined
06:11 harfangk joined
06:12 takle joined
06:16 fhoffmeyer joined
06:17 slomo joined
06:17 slomo joined
06:19 Pupnik_ joined
06:20 systemfault joined
06:23 takle joined
06:28 louispan joined
06:31 hphuoc25 joined
06:34 takle joined
06:45 ThomasLocke joined
06:45 ThomasLocke joined
06:47 patbecich joined
06:53 takle joined
06:57 patbecich joined
06:59 eacameron joined
07:01 takle joined
07:08 andrevdm joined
07:13 Sose joined
07:14 takle joined
07:17 dni- joined
07:17 fhoffmeyer joined
07:19 hdeshev joined
07:31 cur8or joined
07:50 takle joined
07:54 HEGX64 joined
07:57 vmeson joined
07:57 mounty joined
07:58 patbecich joined
07:58 takle joined
07:59 darthdeus_ joined
08:08 nick_h joined
08:09 takle joined
08:09 jathan joined
08:09 hexagoxel joined
08:16 ali_bush joined
08:16 ali_bush joined
08:19 fhoffmeyer joined
08:19 takle joined
08:20 thc202 joined
08:22 dni- joined
08:24 hphuoc25 joined
08:28 louispan joined
08:28 cschneid_ joined
08:29 jmorris joined
08:42 Miroboru joined
08:46 senorchang joined
08:48 takle joined
08:48 merijn joined
08:59 patbecich joined
09:03 kritzcreek_ joined
09:03 zero_byte joined
09:20 fhoffmeyer joined
09:24 grdryn joined
09:25 EO_ joined
09:25 nomotif joined
09:28 Miroboru joined
09:30 glguy joined
09:30 Miroboru joined
09:40 lithie joined
09:51 eacameron joined
09:55 slomo joined
09:55 slomo joined
09:56 permagreen joined
10:00 patbecich joined
10:03 takle joined
10:05 jmorris joined
10:07 takle_ joined
10:08 Gurkenglas_ joined
10:21 fhoffmeyer joined
10:22 andrei_chifa joined
10:27 jmorris joined
10:38 sarkin joined
10:52 hphuoc25 joined
10:53 Gurkenglas_ joined
11:02 patbecich joined
11:16 takle joined
11:23 fhoffmeyer joined
11:34 hexagoxel joined
11:36 andrei_chifa joined
11:47 netheranthem joined
12:02 ederign joined
12:03 patbecich joined
12:03 <Geekingfrog> Is there a package to have a parallel map to do IO action, with a limit on the concurrency level? That is: (a -> IO b) -> [a] -> IO [b] and the provided function executed in parallel.
12:04 <jle`> Geekingfrog: does the async package have what you want?
12:04 <Geekingfrog> I can probably hack something with async, and a shared mvar to act as a semaphore so that other thread will block if the resources are not available
12:04 <jle`> what do you mean by concurrency level...?
12:04 <jle`> maximum number of threads spawned?
12:04 pie_ joined
12:04 <Geekingfrog> That, or maximum number of thread executing concurrently
12:05 <Geekingfrog> I have ~10k action to do, but I want to only perform ~10 at a time
12:06 <Geekingfrog> Using async, I can probably do that with mapConcurrently, and manage the number of running thread using a shared mvar holding the number of resource available.
12:06 <Akii> Geekingfrog: made something similar; maybe you can use it
12:07 <Akii> http://lpaste.net/2237261847604494336
12:08 <Akii> using this to make concurrent geo ip lookups
12:08 <Akii> tested with 7k ips in a queue and 10 concurrent workers
12:08 <Akii> with a bit adoption you can make this a queue of IO actions
12:08 <Akii> s/adoption/customization
12:10 <Geekingfrog> Akii: your solution doesn't preserve the order apparently.
12:10 <Akii> nope
12:11 <Akii> but you can easily attach an integer to the job or smth
12:11 <Geekingfrog> Yes, not a big deal really.
12:12 eacameron joined
12:14 grdryn joined
12:18 Levex joined
12:23 GK___1wm____SU joined
12:23 GK___1wm____SU left
12:24 fhoffmeyer joined
12:26 Levex joined
12:31 eacameron joined
12:35 snowcrshd joined
12:35 cur8or joined
12:37 RusAlex joined
12:43 suls joined
12:53 threestrikes joined
13:00 chlong joined
13:04 patbecich joined
13:05 exferenceBot joined
13:07 exferenceBot joined
13:13 cschneid_ joined
13:13 Levex joined
13:15 Pupnik joined
13:18 Levex joined
13:22 pie_ joined
13:25 fhoffmeyer joined
13:32 madjestic joined
13:37 Cale joined
14:01 harfangk joined
14:04 snowcrshd_ joined
14:06 patbecich joined
14:20 merijn joined
14:22 pie_ joined
14:25 Levex joined
14:26 djfo joined
14:27 fhoffmeyer joined
14:28 suitsmeveryfine joined
14:30 <suitsmeveryfine> Hi! Could someone please explain why GHC infers the Integer type in this function?
14:30 <suitsmeveryfine> f = (\x -> \y -> (if x > y then y else x) + 1)
14:30 pbrant joined
14:30 <merijn> suitsmeveryfine: Defaulting
14:30 <merijn> suitsmeveryfine: This is ghci, yes?
14:31 <merijn> Actually, probably a combination of monomorphism restriction and defaulting
14:31 Cale joined
14:31 <suitsmeveryfine> merijn: OK, but it doesn't to that for this similar function: f x y = (if x > y then y else x) + 1
14:31 Gloomy joined
14:32 <merijn> suitsmeveryfine: The monomorphism restriction is something that applies to things that "don't look like functions", i.e. bindings that have no variables left of the '='
14:32 <merijn> suitsmeveryfine: See: https://wiki.haskell.org/Monomorphism_restriction
14:32 <suitsmeveryfine> merijn: OK, thanks!
14:33 <suitsmeveryfine> need to go. thanks again
14:33 <merijn> Actually, this is a better link: https://stackoverflow.com/questions/32496864/what-is-the-monomorphism-restriction
14:43 initiumdoeslinux joined
14:45 mizu_no_oto_work joined
14:46 mizu_no_oto_work joined
14:48 Levex joined
14:50 eacameron joined
15:03 guampa joined
15:05 Levex joined
15:06 lspitzner joined
15:06 takle joined
15:07 patbecich joined
15:09 mizu_no_oto_work joined
15:12 nick_h joined
15:14 Cale joined
15:14 Levex joined
15:19 nick_h joined
15:28 fhoffmeyer joined
15:32 threestrikes joined
15:39 owiecc joined
15:48 Cale joined
15:53 animated joined
15:56 nick_h joined
15:57 <nitrix> merijn: Would it be possible for GHC to detect that a previously polymorphic function, whose type got changed to a monomorphic one by the monomorphic restriction, is being used with values of different types that it supports, and so, revert the change and keep it polymorphic?
15:58 <merijn> nitrix: Eh, that'd be identical to just disabling the monomorphism restriction. So, yes, you could do that, but that'd defeat the entire point of having it in the first place
15:58 martin3 joined
15:58 <merijn> In that you now, once again, can silently introduce slow down
15:59 <nitrix> No quite. It'd still be allowed to make things monomorphic when it has no other signs that the function is used polymorphically.
15:59 <nitrix> (And thus do optimizations)
15:59 <merijn> nitrix: How is that different from disabling monomorphism restriction?
16:00 <Cale> The monomorphism restriction ought to be a warning.
16:00 <Cale> There are a few cases where the actual restriction makes things more convenient, but in my experience, they're pretty rare.
16:00 <nitrix> If you disable monomorphism restriction, you're commiting on not making things monomorphic so you have many things that could be memoized/shared that wont be.
16:01 <nitrix> But by keeping it on and performing the detection better, you can still optimize some types to be monomorphic.
16:02 <nitrix> It's just the detection that needs to be improved to avoid "false positives".
16:04 <merijn> Honestly, I just don't see a reason to change this behaviour as the current behaviour is about as sane as you can get and working around it is trivial
16:05 <merijn> Cale's suggestion of making it a warning, rather than an error might be an improvement, but I just don't think it's such a big deal
16:05 skeet70 joined
16:05 <nitrix> I believe the problem originates from the type inference system working backwards from the most generic type possible and constraining it further to a more specific type as it goes, but that leaves too many generic types in the end with information is lacking, so we're making all the remainders monomorphic for optimization sake.
16:06 <merijn> nitrix: Not really for optimisation's sake
16:06 <merijn> nitrix: In fact, optimisation has almost nothing to do with the monomorphism restriction
16:06 <nitrix> The problem is that this is done systematically for the remainder of the generic types (based on a few rules like the left hand side and stuff), while it should actually look at usages / call sites.
16:06 <nitrix> And then back propagate that the type shall remain generic.
16:07 <merijn> nitrix: The real problem is: "Do we expect typeclass polymorphic data types to behave the same as data that is not typeclass polymorphic?"
16:07 <nitrix> merijn: You're confused. Memoization and monomorphic restriction goes hand-in-hand.
16:08 <merijn> nitrix: Memoisation is not the right term for what happens with top-level datatypes. And however we decide to call it, it's not an optimisation, it's a fundamental property of how we evaluation of data structures is defined to work in Haskell
16:08 patbecich joined
16:08 <nitrix> It's there as an optimization. By making it monomorphic, you're able to memoize it and shared (memoize) the result.
16:08 <nitrix> It's how our thunks work.
16:08 cschneid_ joined
16:09 <nitrix> It's the sole reason why the rule of monomorphic restriction works by looking at the left-hand side for arguments.
16:10 <merijn> It's "incrementally evaluating our data structures" and it's the behaviour that happens literally everywhere we use data structures in haskell, EXCEPT typeclass polymorphic values. To call it an optimisation is a weird twist of what "normal behaviour" is wrt to data in GHC Haskell
16:10 <nitrix> And the operational difference between `foo = \x -> ...` vs. `foo x = ...`
16:10 zero_byte joined
16:10 <nitrix> merijn: But it's done wrong.
16:10 <merijn> nitrix: How so?
16:11 <nitrix> Not that I can improve the type system myself, but I'm sure we could have a talk with SPJ and he'd word the problem better than I.
16:12 <nitrix> merijn: Because the way it determines what leftover generic types needs to become monomorphic is systematic (based on two arbitrary rules (left hand side and type annotations)), while instead it could figure it all by looking at usages.
16:13 <nitrix> But it means doing type inference backwards and propagating the need of keeping such and such types generic, which would be insane to implement.
16:15 <nitrix> But I'm sure it's doable and the day someone ever gets to it, there'll be no more MR gotchas, talks or even extensions. It'll simply satisfy both camp nicely and instinctively do the right thing.
16:16 <merijn> nitrix: Except when you never intended it to be polymorphic and now it's accidentally stored twice
16:16 <merijn> Instead of giving a type error
16:16 <nitrix> It makes no sense for it to be completely on or completely off.
16:16 <merijn> Honestly, IMO the real mistake is allowing top-level type annotations to be optional
16:17 <nitrix> I think Rust got this right.
16:17 <nitrix> They have complete inference, but you're required to at least provide function annotations.
16:18 <nitrix> merijn: I've hit the MR problem in where clauses too.
16:18 <merijn> nitrix: I always annotate where clauses nowadays too
16:18 <nitrix> Myeah so we should extend your statement that any function should be annotated.
16:18 <nitrix> But then the problem is that, `let x = ...` osm
16:19 <nitrix> *isn't quite a function.
16:20 <nitrix> But it should still be annotated. So now we're annotating everything :P
16:20 <nitrix> Which brings us back to MR and that rule with the left hand side.
16:21 <nitrix> where x = 42; y = (+)
16:23 <nitrix> Here I probably want x to be monomorphic and y to be polymorphic.
16:24 <nitrix> If MR was smart, it'd detect me doing `y 1 1` and `y 1.0 1.0` somewhere in my code and avoid making it monomorphic instead of giving an error.
16:25 <nitrix> merijn: Or am I repeating Cale's idea with the warning?
16:25 <nitrix> It shouldn't even be a warning, how can that not be intentional?
16:27 <nitrix> It's just equational reasoning. (+) is polymorphic... so should be y if used polymorphically. I don't get warnings for doing 1 + 1 and 1.0 + 1.0, I don't see why `y` would get a special treatment.
16:28 djfo joined
16:29 vmeson joined
16:29 fhoffmeyer joined
16:32 nil_ joined
16:44 Levex joined
16:44 mizu_no_oto_work joined
16:44 conal joined
16:44 Deide joined
16:50 owiecc joined
16:53 handlex joined
16:53 vmeson joined
17:09 pie_ joined
17:09 threestrikes_ joined
17:30 fhoffmeyer joined
17:31 vmeson joined
17:32 hvr joined
17:32 hvr joined
17:39 patbecich joined
17:43 jathan joined
17:47 conal joined
17:47 luis3m left
17:49 jathan joined
17:59 djfo left
18:07 mizu_no_oto_work joined
18:13 suitsmeveryfine joined
18:14 Levex joined
18:18 nadirs joined
18:19 mizu_no_oto_work joined
18:21 malaclyps joined
18:22 delexi joined
18:23 freechips joined
18:25 guampa joined
18:32 fhoffmeyer joined
18:32 Levex joined
18:40 patbecich joined
18:44 Levex joined
18:52 pilne joined
18:54 hoffmeyer joined
18:57 Levex joined
19:00 suitsmeveryfine left
19:03 Levex joined
19:04 Cale joined
19:07 threestrikes_ joined
19:12 hoffmeyer joined
19:13 guampa joined
19:15 mengu joined
19:20 simendsjo joined
19:23 mizu_no_oto_work joined
19:29 owiecc joined
19:29 contiver_ joined
19:32 owiecc joined
19:33 fhoffmeyer joined
19:35 andrei_chifa joined
19:39 Miroboru joined
19:42 patbecich joined
19:42 threestrikes_ joined
19:43 hoffmeyer joined
19:44 Levex joined
19:45 malaclyps joined
19:47 carlomagno joined
19:55 takle joined
19:57 fhoffmeyer joined
19:58 conal joined
19:58 andrei_chifa joined
20:04 nomotif joined
20:06 peterbecich joined
20:07 delexi joined
20:15 threestrikes_1 joined
20:15 peterbecich joined
20:17 Levex joined
20:20 ilja_kuklic joined
20:34 Levex joined
20:36 shayan_ joined
20:40 louispan joined
20:43 patbecich joined
20:45 peterbecich joined
20:46 peterbec` joined
20:46 peterbec` joined
20:48 chi_ joined
20:49 t0by joined
20:49 t0by joined
21:09 peterbec` joined
21:15 patbecich joined
21:20 acarrico joined
21:26 andrei_chifa joined
21:52 MarcelineVQ joined
21:53 hiratara joined
21:56 kritzcreek_ joined
22:01 conal joined
22:02 cur8or joined
22:06 threestrikes_1 joined
22:13 pie_ joined
22:13 dosequis joined
22:17 albertus1 joined
22:23 moei joined
22:24 moei joined
22:27 steven_yvr joined
22:27 louispan joined
22:31 hiratara joined
22:38 malaclyps joined
22:42 threestrikes_1 joined
22:43 louispan joined
22:47 albertus1 joined
22:57 albertus1 joined
22:59 Gloomy joined
23:01 andrei_chifa joined
23:10 peterbec` joined
23:12 louispan joined
23:14 albertus1 joined
23:17 conal joined
23:21 anoe joined
23:21 mitchty joined
23:24 LiaoTao joined
23:25 emmanuel` joined
23:27 Zialus joined
23:28 mitchty joined
23:30 albertus1 joined
23:39 earldouglas joined
23:45 NoCreativity joined
23:48 mac10688 joined
23:52 mounty joined