<    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 24 25  
26 27 28 29 30 31
00:00 louispan joined
00:03 peterbec` joined
00:09 tom7942 joined
00:11 Rodya_ joined
00:16 louispan joined
00:19 Rodya_ joined
00:20 <bitemyapp> hmm
00:25 vicsy left
00:28 <MarcelineVQ> hmm~
00:28 louispan joined
00:28 NoCreativity joined
00:31 vaibhavsagar joined
00:41 bungoman joined
00:58 pietilson joined
00:59 uglyfigurine joined
00:59 uglyfigurine joined
01:08 <bitemyapp> MarcelineVQ: someone said my name, but it's too far back for lastlog.
01:10 <geekosaur> only thing I see is someone thanking you, a bit after the fact
01:11 <bitemyapp> nothing actionable then, thank you geekosaur
01:11 <MarcelineVQ> yes closest thing was a thank you for "How can I disable migrations in Yesod? I can't find the setting."
01:14 splanch joined
01:14 [k- joined
01:15 eacameron joined
01:15 <MarcelineVQ> 18 hours later <geekosaur> hmm. someone said my name, but it's too far back for lastlog.
01:20 splanch joined
01:22 peterbec` joined
01:25 ExpHP joined
01:26 louispan joined
01:45 louispan joined
01:47 chlong joined
01:50 mac10688 joined
01:53 qu1j0t3 joined
02:10 Gurkenglas_ joined
02:19 peterbecich joined
02:21 davesq joined
02:21 exferenceBot joined
02:23 eacameron joined
02:23 peterbec` joined
02:26 hexagoxel joined
02:28 eacameron joined
02:31 conal joined
02:32 Haruna joined
02:33 louispan joined
02:33 Guest30884 joined
02:33 Guest30884 joined
02:38 argent0 joined
02:39 <argent0> hi, so `List a = Maybe (NonEmptyList a)`?
02:41 <kadoban> argent0: That seems like an acceptable definition in terms of meaning, sure.
02:46 <benzrf> argent0: define "=" :)
02:47 <benzrf> there's a natural isomorphism, certainly
02:47 splanch joined
02:48 <argent0> benzrf: kadoban: I was wondering what would make the "the same" type too
02:48 <kadoban> argent0: I don't understand
02:48 <argent0> is [a] "the as
02:48 <argent0> is [a] "the as" List a
02:49 <benzrf> argent0: you mean "the same as"?
02:49 <kadoban> I understand less?
02:49 ljc joined
02:50 mac10688 joined
02:50 <argent0> benzrf: yes, sorry
02:51 <benzrf> argent0: "List" isnt the name of a type in base, afaik
02:51 <benzrf> people occasionally write List instead of [] if they want to use normal prefix notation to talk about it without looking awkward
02:51 <kadoban> In a sense it's the same. Haskell won't think so obviously, but for every value of type Maybe (NonEmptyList a) there is exactly one value of type [a], and the other way around too.
02:52 <kadoban> But I have a feeling I'm still missing something in the question.
02:52 <benzrf> kadoban: that's true, but you could say the same of Int and Rational
02:52 <benzrf> er, Integer :)
02:52 <benzrf> i think the crux is the existence of a natural isomorphism
02:52 <kadoban> Yes, you could, which indeed might make it less compelling information, but I don't know how to state it in a more compelling way.
02:53 <argent0> kadoban: That was the point, and if there would be 'advantages' of `List a` over (Maybe (NonEmptyList a)), or the other way around
02:54 <benzrf> argent0: not really
02:55 <kadoban> Well, syntactically, Maybe (NonEmptyList a) might be a tad tedious, I guess? It might be bad just because people expect that to be called [a], and breaking conventions for no substantial gain is usually not a good idea.
02:56 <kadoban> And anything that outputs or takes a list will require a conversion function, so that'd suck a decent amount too.
02:59 <argent0> kadoban: yes I was writing some instances and, for one, you can't pattern match
03:01 <kadoban> argent0: I think you can, but it's tediousish. f (Just (x :| xs)) = <stuff> and then handle the Nothing case too
03:02 <geekosaur> there's also pattern synonyms, but that's got its own tedium
03:03 mazeinmaze joined
03:07 conal joined
03:10 splanch joined
03:10 vaibhavsagar joined
03:19 <argent0> but, there is Data.Functor.Compose: So one could define: `type List = Data.Functor.Compose Maybe NonEmpotyList` and the Functor instance is comes from the composition.
03:21 <argent0> and Applicative, Foldable, and others... So there is that
03:22 hphuoc25 joined
03:25 peterbec` joined
03:40 tolt left
03:55 justicefries joined
04:03 hphuoc25 joined
04:07 splanch joined
04:11 takle joined
04:19 animated joined
04:21 ali_bush joined
04:21 ali_bush joined
04:23 peterbec` joined
04:25 eacameron joined
04:30 takle joined
04:36 bitemyapp joined
04:36 Kongaloosh joined
04:36 louispan joined
04:40 dobson joined
04:41 pie___ joined
04:47 takle joined
04:49 hphuoc25 joined
04:49 malaclyps joined
04:54 hphuoc25_ joined
04:55 takle joined
05:01 DataComputist joined
05:08 Ferdirand joined
05:20 takle joined
05:22 delexi joined
05:25 meandi_2 joined
05:33 benzrf joined
05:34 machuga joined
05:35 stvc joined
05:36 splanch joined
05:36 jud^ joined
05:38 takle joined
05:43 takle joined
05:48 yellowj joined
05:58 splanch joined
05:58 takle joined
06:01 uglyfigurine joined
06:05 hphuoc25 joined
06:05 takle joined
06:08 peterbec` joined
06:13 takle joined
06:14 andyhoang joined
06:27 takle joined
06:29 raduom joined
06:33 ego joined
06:33 louispan joined
06:35 t0by joined
06:41 Sose joined
06:44 takle joined
06:46 hdeshev joined
06:52 takle joined
06:52 thc202 joined
06:54 Xlaech joined
06:59 louispan joined
07:04 buoto joined
07:07 cur8or joined
07:09 kritzcreek_ joined
07:10 eacameron joined
07:14 mattyw joined
07:15 buoto joined
07:16 eacameron joined
07:17 hphuoc25 joined
07:27 hphuoc25_ joined
07:28 takle joined
07:28 DataComputist joined
07:30 DataComputist joined
07:33 DataComputist joined
07:33 DataComputist joined
07:34 DataComputist joined
07:35 takle joined
07:40 Gloomy joined
07:41 DataComputist joined
07:42 mcspud joined
07:44 DataComputist joined
07:45 takle joined
07:48 MarcelineVQ joined
07:49 DataComputist joined
07:49 DataComputist joined
07:49 DataComputist joined
07:50 Durz0 joined
07:51 nacon joined
07:51 nacon joined
07:52 eacameron joined
07:52 hphuoc25 joined
07:53 gregman_ joined
07:53 grayjoc joined
07:53 DataComputist joined
07:54 DataComputist joined
07:56 takle joined
07:59 hphuoc25 joined
08:02 prophile joined
08:07 peterbec` joined
08:10 zero_byte joined
08:13 louispan joined
08:15 conal joined
08:17 louispan joined
08:18 nil_ joined
08:20 merijn joined
08:21 colt44 joined
08:24 louispan joined
08:31 grdryn joined
08:34 korayal[m] joined
08:36 nokomo joined
08:44 permagreen joined
08:47 poundbear joined
08:47 vito_swiss joined
08:50 <poundbear> Hi can someone explain to me whats wrong here? I want to get the length of each list in the list
08:50 <poundbear> tidyData2 :: [[Integer]] -> [Integer] tidyData2 lis = map length lis Input: [[0], [1,2,3,4], [3,4,2]] Expected type: [Integer] -> Integer Actual type: [Integer] -> Int
08:50 <sshine> :t length
08:50 <lambdabot> Foldable t => t a -> Int
08:50 <sshine> Int an Integer are different types.
08:50 <sshine> :t genericLength
08:51 takle joined
08:51 <lambdabot> Num i => [a] -> i
08:51 <poundbear> sorry http://lpaste.net/354094
08:51 <sshine> > map genericLength [[1,2,3],[4,5],[6,7,8,9]] :: [Integer]
08:51 <lambdabot> [3,2,4]
08:51 <jle`> :t fromIntegral . length
08:51 <lambdabot> (Foldable t, Num c) => t a -> c
08:51 <sshine> your type signature insists on Integer, but 'length' is Int. so either change the signature to use Int, or use 'genericLength' in the standard library. :)
08:52 <jle`> :t fromIntegral . length :: [a] -> Int
08:52 <lambdabot> [a] -> Int
08:52 <merijn> poundbear: length doesn't return an Integer :)
08:52 <jle`> :t fromIntegral . length :: [a] -> Integer
08:52 <lambdabot> [a] -> Integer
08:52 <jle`> > map (fromIntegral . length) [[12,3],[4,5],[6,7,8,9]] :: [Integer]
08:52 <lambdabot> [2,2,4]
08:53 poundbear joined
08:53 hphuoc25 joined
08:54 infinite-Joy314 joined
08:54 <poundbear> wow thanks guys!
08:56 <jle`> btw i do recommend 'fromIntegral . length' over genericLength in most cases
08:57 <jle`> it doesn't matter for short lists, but genericLength is extremely space- and time-wasteful
08:57 <jle`> so it's a bad idea in general
08:57 ThomasLocke joined
08:58 <poundbear> alright thanks!
08:58 louispan joined
09:01 <nil_> Why does length return Int again? Performance reasons?
09:01 <merijn> nil_: Performance + historical reasons
09:02 <merijn> Mostly the latter :p
09:03 <jle`> i don't think Integer vs. Int would make an impact on performance here
09:03 <jle`> but it's Int vs. forall a. Num a => a that causes the issues
09:08 peterbec` joined
09:09 infinite-Joy314 joined
09:19 pie___ joined
09:20 louispan joined
09:21 Majiir joined
09:22 splanch joined
09:22 galderz joined
09:23 Gloomy joined
09:27 galderz joined
09:27 corintho[m] joined
09:27 hphuoc25 joined
09:29 vaibhavsagar joined
09:32 sudoreboot[m] joined
09:32 dyce[m] joined
09:32 agates joined
09:32 prose[m] joined
09:32 unclechu joined
09:32 curry[m] joined
09:32 korayal[m] joined
09:37 qu1j0t3 joined
09:37 <nil_> When a CT text talks about "the endofunctor F: X → 1 + X" can I just read "Maybe X"?
09:38 uglyfigurine joined
09:47 <jle`> nil_: you can read F is Maybe, yes
09:47 <jle`> F(X) is Maybe X
09:48 <nil_> That's what I thought (or hoped), thanks.
09:49 <nil_> And (Maybe Void) ≅ Nat (= Zero | Succ Nat), right?
09:49 <nil_> (Context: I'm reading the nlab take on induction over the natural numbers.)
09:50 louispan joined
09:51 <jle`> Maybe Void is definitely not Nat
09:51 <nil_> :(
09:51 <jle`> if Void is the typical Haskell usage of it, data Void, or 0
09:52 <jle`> if Maybe(X) = 1 + X, then Maybe(0) = 1 + 0 = 1
09:52 <jle`> the only inhabitant of `Maybe Void` is `Nothing :: Maybe Void`
09:52 <nil_> Yeah, that's why I thought it would fit the bill.
09:52 <jle`> but, Nat has more than 1 inhabitant
09:52 <nil_> @def type Nat = Maybe Void
09:52 <jle`> it has very many
09:52 <lambdabot> Defined.
09:53 <jle`> here are a couple:
09:53 <nil_> @def zero = Nothing :: Nat
09:53 <lambdabot> Defined.
09:53 <jle`> 1, 2, 3
09:53 <nil_> > Just $ Just $ Just zero
09:53 <lambdabot> Just (Just (Just Nothing))
09:53 <nil_> What's wrong with this?
09:53 <jle`> that's not Nat
09:53 <jle`> its type is ont Nat
09:53 <nil_> I don't get it.
09:53 <jle`> its type is Maybe (Maybe (Maybe a))
09:53 <jle`> for some a
09:53 <nil_> Oh
09:53 <nil_> Damn, I'm stupid.
09:53 <jle`> > Just (Just (Just Nothing)) :: Nat
09:54 <lambdabot> error:
09:54 <lambdabot> • Couldn't match type ‘Maybe (Maybe (Maybe a0))’ with ‘Void’
09:54 <lambdabot> Expected type: Nat
09:54 <jle`> you seem to have understood that there is only one inhabitant of Maybe Void
09:54 <jle`> it's zero
09:54 <jle`> there are no others
09:54 <nil_> Okay, how to model Nat then?
09:54 <jle`> data Nat = Zero | Succ Nat works, doesn't it?
09:55 <nil_> It does, I just thought I would be able to reduce Maybe to it somehow.
09:55 <nil_> I guess not then?
09:55 <jle`> well, it's recursive, and Maybe isn't recursive
09:56 <jle`> but, Nat is the fixed point of Maybe
09:56 <nil_> AH HAH!
09:56 <nil_> I knew there was some magic going on here.
09:56 <jle`> Nat ~ Maybe (Maybe (Maybe (Maybe .. forevevr)))
09:56 <nil_> Cool :)
09:56 <jle`> if you had 'data Fix f = F (f (Fix f))'
09:56 <nil_> Where did you pick that up btw?
09:56 <jle`> then Nat ~ Fix Maybe
09:57 infinite-Joy314 joined
09:57 <jle`> Nat being Fix Maybe is one of the textbook examples of fixed point recursion for types
09:57 <jle`> so it usually comes up as one of the first examples, heh
09:58 <nil_> Did you mean 'data Fix f = _Fix_ (f (Fix f))'?
09:58 <jle`> yeah, that's just a convenient newtype wrapper version, though
09:59 <jle`> `Fix Maybe` is basically Maybe applied to itself forever
09:59 <jle`> but there are other ways to implement fix-point recursive types in haskell
09:59 <jle`> oh, are you talking about me using 'F' as the constructor instead of 'Fix'?
09:59 <jle`> the constructor name is kind of arbitrary
09:59 <nil_> I am
10:00 <nil_> Oh, right
10:00 <jle`> it could have been data Fix f = Floopy (f (Fix f))
10:00 <nil_> Yeah, okay, got it.
10:00 poundbear joined
10:00 <Geekingfrog> Why is there a lot of code written this way: foo = loop where loop = do [...] loop instead of foo = do [...] foo ?
10:01 <jle`> just in a vacuum it's hard to say
10:01 <jle`> but there might be some reasons in specific cases
10:01 <jle`> to save allocation or to pass parameters or something
10:01 <Geekingfrog> I saw that a lot in the conduit library
10:02 <Geekingfrog> Also in megaparsec sometimes
10:02 <jle`> if you show me a specific case then i might be able to explain that case
10:03 <MarcelineVQ> Geekingfrog: you don't mean things like 'go' where paramaters are being passed to a worker function do you?
10:03 <nil_> What do angle brackets mean in a CT context? <0,s> == ?
10:04 <Geekingfrog> jle` MarcelineVQ http://hackage.haskell.org/package/conduit-combinators-1.1.1/docs/Data-Conduit-Combinators.html#v:takeWhile for example
10:05 <jle`> Geekingfrog: in that case, it's to re-use the f parameter so you don't allocate a new function call every time
10:06 <jle`> Geekingfrog: it's calling 'loop' repeatedly
10:06 <jle`> if you written it directly in takeWhile f = ..., it would be calling 'takeWhile f' repeatedly
10:06 <jle`> but every time ot calls 'takeWhile f', it has to apply f to takeWhile, again
10:07 <Geekingfrog> makes sense.
10:07 <jle`> but if you just called 'loop' repeatedly, it doesn't have that extra function application. loop exists in one place in memory for the duration of its existence
10:07 <Geekingfrog> What about takeE just above ?
10:08 <Geekingfrog> It seems in that case calling directly takeE i would be the same no ?
10:09 <MarcelineVQ> I think it's to due with inlining there, takeE not waiting for more arguments, by having loop wait for them instead, means it can be inlined better. I don't know much about inline rules though
10:09 <MarcelineVQ> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#inline-and-noinline-pragmas
10:09 <jle`> maybe calling `takeE i` would re-allocate a 'go' function evrey time
10:10 peterbec` joined
10:10 <jle`> or yeah, it could be better when inlining takeWhileE; having go/loop as separate ensures that the top-level call is never inlined
10:10 <MarcelineVQ> "Moreover, GHC will only inline the function if it is fully applied, where “fully applied” means applied to as many arguments as appear (syntactically) on the LHS of the function definition." takeE has no arguments on the syntactic left side of =
10:10 <jle`> or it might just be for consistency
10:13 andyhoang joined
10:15 HardcoreVibes joined
10:15 <HardcoreVibes> guys, why does this doesnt work: filter ((`mod` 3)==0) [1..99]
10:15 <jle`> what do you mean by "doesn't work"
10:16 <HardcoreVibes> it outputs error
10:16 <jle`> what is the error?
10:16 <HardcoreVibes> can i try the command here?
10:16 <jle`> sure
10:16 <HardcoreVibes> how? i dont know the syntax
10:16 <jle`> > filter ((`mod` 3) == 0) [1..99]
10:16 <lambdabot> error:
10:16 <lambdabot> • Couldn't match expected type ‘a -> Bool’ with actual type ‘Bool’
10:16 <lambdabot> • Possible cause: ‘(==)’ is applied to too many arguments
10:17 <jle`> do you know what (`mod` 3) is?
10:17 <HardcoreVibes> modulus 3
10:17 <jle`> it's a function, right?
10:17 <HardcoreVibes> yes
10:17 <jle`> so why are you comparing a function to 0?
10:17 <jle`> you can only use == on things of the same type
10:18 <jle`> so on one side you have (`mod` 3), a function
10:18 <jle`> and on the other side you have 0, a number
10:18 <jle`> doesn't quite make sense, right?
10:18 <jle`> > "hello" == True
10:18 <lambdabot> error:
10:18 <lambdabot> • Couldn't match expected type ‘[Char]’ with actual type ‘Bool’
10:18 <lambdabot> • In the second argument of ‘(==)’, namely ‘True’
10:18 <jle`> > ('a',7) == "koala"
10:18 <lambdabot> error:
10:18 <lambdabot> • Couldn't match expected type ‘(Char, Integer)’
10:18 <lambdabot> with actual type ‘[Char]’
10:18 <jle`> (==) only works on things that are the same type
10:18 <HardcoreVibes> jle`, i guess i see your point. is there a different way to write it?
10:19 <jle`> well, what do you want to write?
10:19 <jle`> what do you want it to do?
10:19 rabbi1 joined
10:19 <HardcoreVibes> just print the numbers who mod 3 == 0 without multiplying trick
10:19 <HardcoreVibes> from [1..99]
10:20 <jle`> can you write a function that takes a number and returns whether or not you want it to be kept?
10:20 <jle`> maybe write it as a lambda, (\x -> ... ??? ...)
10:20 <HardcoreVibes> this is the only way?
10:20 <jle`> there are several ways, of course
10:20 <jle`> to define a function
10:20 <jle`> you can give it a name too, in a 'where' or 'let' clause
10:21 <HardcoreVibes> ok, thanks a lot
10:21 <jle`> @let isDivisibleByThree x = (x `mod` 3) == 0
10:21 <lambdabot> Defined.
10:21 <jle`> > filter isDivisibleByThree [0..99]
10:21 <lambdabot> [0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75,7...
10:21 <HardcoreVibes> im just exploring haskell atm
10:21 <jle`> > filter (\x -> (x `mod` 3) == 0) [0..99]
10:21 <lambdabot> [0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75,7...
10:22 <jle`> > filter ((== 0) . (`mod` 3)) [0..99]
10:22 <lambdabot> [0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75,7...
10:22 <jle`> you can provide anything as long as it's a function 'Int -> Bool', that does what you want it to do
10:23 <jle`> `(`mod` 3) == 0` is certainly not a function from Int -> Bool...it seems to just be a Bool?
10:23 <jle`> there are many ways to write your function, but as long as it's an 'Int -> Bool', you are fine :)
10:28 marvin2 joined
10:28 marvin2 left
10:29 netheranthem joined
10:30 marvin2 joined
10:30 Gurkenglas_ joined
10:35 andyhoang joined
10:48 louispan joined
10:51 snowcrshd joined
10:59 Gloomy joined
11:02 Prutheus joined
11:04 merijn joined
11:09 mengu joined
11:10 peterbec` joined
11:12 nil_ joined
11:13 <ski> __rgn : "wrt. \"pointed functor\", what does pointed mean?","i understand what those are, but why \"pointed\"" -- in math, a pointed set is a set where we've singled out a particular element (any element) as "special". this means first and foremost that the set must be non-empty, but we've done more than that, we've selected a particular point (sometimes called "basepoint"). there's also pointed topological spaces, &c.
11:14 <ski> __rgn : by abstract nonsense (see category theory), for functors it turns out that "pointed functor" means that we have a functor, call it `f', and a polymorphic function (really a natural transformation) of type `forall a. a -> f a', in some sense "singling out" a way to embed an inhabitant of an arbitrary type `a' into the type `f a' (e.g. if `f' is `[]', generating a singleton list. or generating an infinite repeating list. there's lots of opt
11:14 <ski> nil_ : "What do angle brackets mean in a CT context? <0,s> == ?" -- sometimes (also in a more general math context, e.g. algebra), it's just a different notation for tuples, here pairs. if used on morphisms `f : T >---> A',`g : T >---> B', then `<f,g> : T >---> A * B' is the "tupling" of them (`\t -> (f t,g t)', aka `f &&& g')
11:14 <ski> nil_ : also, if `f : A >---> P',`g : B >---> P', then `[f,g] : A + B >---> P' is the "cotupling" (`\case Left a -> f a; Right b -> g b', aka `either f g' aka `f ||| g')
11:14 <nil_> @karma++ ski
11:14 <lambdabot> ski's karma raised to 52.
11:15 <* ski> twitches
11:17 <nil_> What's the matter?
11:18 <ski> (btw, to make it clear. `&&&' and `|||' are not used in a CT context, those are just the operations in `Control.Arrow')
11:18 <nil_> Understood. :)
11:19 poundbear joined
11:19 <* ski> doesn't believe in manually attempting to keep track of karma, points, likes, dislikes, shares, &c.
11:20 <nil_> In honor of your credo I will undo the "karma++" if you can provide a retraction.
11:20 <ski> "provide a retraction" means ?
11:21 <nil_> For any x: x == (karma++Inv . karma++) x ; provide karma++Inv.
11:22 <ski> ah, that kind of retraction ;)
11:22 <nil_> (I hope I'm using the right word.)
11:23 <ski> it's `karma-', actually even inverse of `karma+'
11:23 <nil_> @karma- ski
11:23 <lambdabot> ski's karma lowered to 51.
11:23 <* ski> smiles
11:23 <nil_> May you be enlightened instead.
11:23 <ski> hahah
11:24 <nil_> Or may you trip over a bag of cash, if you like that one better. :)
11:39 hphuoc25 joined
11:47 pbrant joined
11:51 mengu_ joined
11:51 <nil_> Fokkinga's language is a little... off.
11:52 <nil_> I mean the English, not the technical terms obv.
11:54 mcspud joined
11:59 jgertm- joined
12:01 eacameron joined
12:01 takle joined
12:05 ederign joined
12:08 geekosaur joined
12:11 peterbec` joined
12:14 mengu joined
12:21 cur8or joined
12:30 merijn joined
12:35 eacameron joined
12:36 grayjoc joined
12:41 ExpHP joined
12:43 for{} joined
12:43 <for{}> hi
12:44 <for{}> why `aaa =nub.replicate` is incorrect while `aaa x =nub.replicate x` is correct?
12:46 <for{}> `aaa=length.nub` is correct too
12:47 splanch joined
12:49 eacameron joined
12:50 <ski> aaa = (nub .) . replicate
12:50 <ski> `nub.replicate x' means `nub.(replicate x)', iow `(nub .) (replicate x)', iow `((nub .) . replicate) x'
12:51 <ski> so you get `aaa x = ((nub .) . replicate) x' which can be "shortened" (function extensionality, related to eta-contraction) into `aaa = (nub .) . replicate'
12:51 hphuoc25 joined
12:51 <ski> this is because you want to "pass on" *two* (not one) arguments to `replicate'
12:52 <for{}> what is iow?
12:55 <for{}> `aaa=(nub.).replicate` is recommended/better than `aaa x =nub.replicate x`?
12:57 rabbi1 joined
12:58 merijn joined
12:59 <for{}> i mean as a style of writing haskell code
13:00 <for{}> not as correctness
13:01 <for{}> thanks for clarification
13:02 <mniip> iow = in other words
13:03 <for{}> mniip, is `aaa=(nub.).replicate` recommended/better than `aaa x =nub.replicate x`?
13:03 <mniip> that's hard to say
13:04 <mniip> I would prefer the first but only because I know what (.) . (.) means
13:04 <mniip> in a library you might want to use the latter
13:04 <for{}> ok
13:08 <nil_> There's a library combinator called (.:) in Data.Composition (package "composition") that does that fwiw.
13:09 <merijn> I wouldn't recommend it, tbh
13:09 <nil_> :(
13:09 <nil_> I use it all the time and it keeps me happy.
13:10 <merijn> I find it fairly unreadable, tbh
13:11 <nil_> merijn: compared to the orthodox (\f g -> (f .) . g) or to the pointful version?
13:12 peterbec` joined
13:12 <merijn> nil_: I don't like (f .) . g either :)
13:12 <merijn> I'd just use names
13:12 <nil_> I guess it's a matter of taste.
13:13 uglyfigurine joined
13:14 eacameron joined
13:16 eacameron joined
13:16 hphuoc25 joined
13:18 Deaddy joined
13:27 vmeson joined
13:27 hphuoc25 joined
13:29 hphuoc25 joined
13:30 rabbi1 joined
13:34 chlong joined
13:44 pie_ joined
13:44 buoto joined
13:45 <__rgn> i understand ((+) <$> (+2) <*> (*2)) 5 "becomes" (+ (2 + 5) (2 * 5)), but not *why* <*> behaves that way. why is it that (+2) and (*2) are applied to 5 before their result being applied to (+)
13:45 <merijn> __rgn: Well, let's see!
13:45 <merijn> :t (<*>)
13:45 <lambdabot> Applicative f => f (a -> b) -> f a -> f b
13:46 <merijn> __rgn: Right, so the first question to ask ourselves is: What is 'f' here?
13:46 <merijn> :t (+)
13:46 <lambdabot> Num a => a -> a -> a
13:46 <__rgn> (<*>) :: (a -> a -> b) -> (a -> a) -> (a -> b)
13:47 <merijn> Well, it might be clearer if we write it like this:
13:47 <__rgn> so on the left side of <*> must be a function that takes two arguments
13:47 <merijn> 'f = (->) r'
13:47 <merijn> So
13:47 <merijn> (<*>) :: (r -> (a -> b)) -> (r -> a) -> (r -> b)
13:48 <merijn> If you stare at that long enough, you can see that there's only one thing it *can* do
13:49 <merijn> It can only get a function 'a -> b' by applying an 'r' to the first function
13:49 <merijn> The only we to obtain an 'a' is to apply an 'r' to the function 'r -> a'
13:50 <merijn> So, the only way we can make 'r -> b' is by feeding an 'r' to both 'r -> a -> b' and 'r -> a' and applying the resulting 'a -> b' to the resulting 'a'
13:51 andyhoang joined
13:52 expo873 joined
13:52 mizu_no_oto_work joined
13:53 <merijn> __rgn: Make sense? :)
13:55 <__rgn> the letters by themselves don't make sense to me, i'm trying to map that signature to the example
13:55 <merijn> __rgn: Well, in the example 'r', 'a' and 'b' all end up being the same type
13:55 <merijn> __rgn: Which makes it hard to see that there's only 'one thing' it can do
13:56 <merijn> Since we're mapping 'r -> (a -> b)' to 'a -> a -> a' we can conclude 'r = a', 'a = a', 'b = a'
13:56 <nil_> Parametricity is awesome.
13:56 <merijn> __rgn: But since <*> is defined more generally (like the type I gave) you know it can't be doing anything else
13:57 <merijn> Since the implementation can't depend on the actual types of 'r', 'a', and 'b'
13:57 <merijn> __rgn: The letters not making sense is exactly why it works :)
13:57 <merijn> __rgn: They can be *anything* and <*> can't change based on it :)
14:00 <merijn> Consider, for example this use of <*>
14:01 <merijn> > [elem] <*> [1,2,5] <*> [[1..4], [5..10], [1..10]]
14:02 <lambdabot> [True,False,True,True,False,True,False,True,True]
14:02 <merijn> __rgn: Now we have: 'f = []'
14:02 <merijn> So "(<*>) :: [a -> b] -> [a] -> [b]"
14:04 <merijn> With, in my example, 'b = Int -> Bool' for the first one and 'b = Bool' for the second <*>
14:05 jathan joined
14:10 <__rgn> i believe i do have better understanding of <*> in context of lists
14:11 <merijn> __rgn: Try taking my type of 'f = (->) r' and doing the substitution by hand on paper :)
14:11 harfangk joined
14:11 <__rgn> on what?
14:11 <__rgn> type of <*>?
14:12 <merijn> __rgn: Yes, and then filling in the types of (+) and (+2)
14:13 peterbec` joined
14:23 earldouglas joined
14:27 <__rgn> how am i supposed to understand (-> r) as
14:27 snowcrshd joined
14:27 <merijn> '(->) r' = (r ->)
14:28 <nil_> (i.e., forall a. r -> a)
14:28 <__rgn> it looks like a function that is missing an argument
14:28 carlomagno joined
14:28 <merijn> __rgn: Yes, it's a partially applied type
14:28 <merijn> __rgn: You know how "(+) 2 2" = "2 + 2"?
14:28 <__rgn> yes
14:29 <merijn> __rgn: "(->) a b" = "a -> b" :)
14:29 <__rgn> (->) partially applied with r?
14:29 <merijn> __rgn: Yeah
14:29 <merijn> __rgn: Are you familiar with kinds?
14:29 <__rgn> sort of
14:30 <merijn> __rgn: Basically, kinds are the "types of types" and "all types that have values (e.g. Int) have kind *"
14:30 <merijn> __rgn: So "Int :: *", "Bool :: *", "Maybe Int :: *" and "Maybe :: * -> *"
14:30 <merijn> Especially the last one is relevant
14:31 mcspud joined
14:31 <merijn> It says "Maybe" is a type that, when given another type, produces a new type that has values
14:31 <merijn> Side note, the -> in types and in kinds is different, so lets use ~> for kinds to avoid confusion
14:31 <merijn> So "Maybe :: * ~> *"
14:32 <merijn> Well, then, what's the kind of (->)?
14:32 <merijn> Hopefully "(->) :: * ~> * ~> *" make some sense :) It's a type that takes 2 types as argument, producing a new function type :)
14:32 delexi joined
14:33 <mniip> nit: Void?
14:33 <merijn> If we look at <*> which works on Applicative, then we see that Applicatives always have kind "* ~> *" (for example, [], Maybe, IO, Either e, etc.)
14:34 <merijn> __rgn: So '(->)' can't be an Applicative, for the same reason that '(,)' or Either can't! They all have kind '* ~> * ~> *'
14:34 <merijn> But if we partially apply those types, e.g. '(,) a', 'Either e', '(->) r' we suddenly get types that *do* have kind '* ~> *' so they can be made applicatives
14:34 <__rgn> how is * ~> * supposed to be interpreted as, takes one any type and ....
14:35 tdfirth joined
14:35 <mniip> nil_, forall a. r -> a is different
14:35 <merijn> __rgn: Takes any type of kind * and returns a new type of kind *
14:35 <mniip> that's a kind-* type
14:35 <nil_> mniip: it is?
14:35 <merijn> __rgn: (note: all types that have values have kind *, but not all types have kind *)
14:35 <merijn> Since not all types have values
14:35 <merijn> For example, the type "Maybe" has no values
14:35 <merijn> but "Maybe Int" does
14:36 <merijn> "Maybe Maybe" also doesn't make sense
14:36 <__rgn> what does Maybe Int :: * mean
14:36 <merijn> Since then we could have "Just ??" ?? would have type Maybe, but we can't have values of type Maybe
14:36 <__rgn> why is there a * if the type is already settled
14:36 <merijn> __rgn: It means the type "Maybe Int" has kind *
14:37 <merijn> "Int :: *" (Int has kind *) and "Maybe :: * ~> *" (Maybe has kind * ~> *), so logically 'Maybe Int :: *' (Maybe Int has kind *)
14:42 <__rgn> so in my example every type variable in the signature of <*> essentially become `a` because they're the same type
14:43 <merijn> __rgn: Because (+) has the same type for both its inputs and result, yes
14:46 Gurkenglas_ joined
14:47 <for{}> `data Anniversary = Birthday String Int Int Int` creates among others a typeclass?
14:47 <Cale> merijn: Wait, what's with the squiggly arrows?
14:47 <Cale> @kind Maybe
14:47 <lambdabot> * -> *
14:48 <for{}> i mean Anniversary is a typeclass while Birthday is a type?
14:48 <Cale> for{}: No
14:48 <Cale> Anniversary is a type
14:48 <Cale> (and type constructor)
14:48 <Cale> Birthday is a data constructor
14:48 <merijn> Cale: Avoiding ambiguity, as I mentioned a while back
14:48 <Cale> ah
14:48 <Cale> sorry :)
14:48 hphuoc25 joined
14:49 <for{}> Cale, why do we need a type constructor and a data constructor?
14:49 <merijn> Cale: I've noticed that, when explaining kinds to people, especially when including functions people tend to get caught up thinking -> at the type level is somehow related to -> at the kind level
14:49 <merijn> Cale: So I find it safest to explicitly use different notation when I'm refering to kind level -> :)
14:49 <Cale> for{}: Okay, so there are two worlds: there's the world of terms, which live on the left hand side of the ::
14:50 <merijn> Cale: Same issue with beginners getting confused with "data Foo = Foo" mistaking type and value :)
14:50 <Cale> for{}: These are things which exist at runtime, they can consume memory and such.
14:50 <Cale> for{}: Then there's the world of types, the things which occur on the right side of the ::
14:51 <Cale> These only exist at compile time, they're checked and then thrown away
14:51 <Cale> When you write a data declaration, you introduce a new type (which in this case is called Anniversary)
14:51 <Cale> as well as introducing new terms for constructing values of that type
14:52 <Cale> Your data declaration there will define a function: Birthday :: String -> Int -> Int -> Int -> Anniversary
14:52 <Cale> which will be the new primitive way of constructing values of type Anniversary
14:53 <for{}> can we build typeclasses too?
14:53 <Cale> Yes, type classes are used to constrain the types over which type variables range
14:54 <Cale> For example, there is a type class called Eq defined as follows:
14:54 <for{}> how do we build type classes?
14:54 <Cale> class Eq a where
14:54 <Cale> (==) :: a -> a -> Bool
14:54 <Cale> (/=) :: a -> a -> Bool
14:54 <Cale> x /= y = not (x == y)
14:55 <for{}> i know about Num in haskell, but i wonder if i can build another type class
14:55 <Cale> So, here, we define the types of a bunch of values which are the "methods" of the class, making use of the variable which is constrained by it
14:55 <Cale> and then we're also allowed to provide default implementations of those methods
14:55 <Cale> which will be used in case some instance doesn't explicitly provide an implementation
14:56 <Cale> You can do the same on your own, we could have
14:56 Gloomy joined
14:56 <Cale> class Fleemable a where
14:56 <Cale> fleem :: a -> a
14:56 <Cale> for example
14:56 <Cale> and then we can write instances of this class to define what the operation fleem does for various specific types
14:57 <for{}> Cale, thanks a lot
14:57 vicfred joined
14:58 <Cale> instance Fleemable Integer where
14:58 <Cale> fleem n = if even n then n `div` 2 else 3 * n + 1
14:58 <Cale> instance Fleemable a => Fleemable [a] where
14:58 <Cale> fleem xs = map fleem xs
14:58 <for{}> Cale, what books would you recommend to understand haskell?
14:59 <Cale> Graham Hutton's book looks solid to me
14:59 <for{}> how did you learn and understand thoroughly haskell?
14:59 <Cale> It's been quite a long time since I learned Haskell, so most of the resources that I learned from are now out of date
15:00 <Cale> (I started learning Haskell in 2001)
15:00 <for{}> Cale, a few good books about fp would be useful in learning haskell?
15:01 <for{}> i dont know how much is haskell and how much is fp in any book i read
15:01 <for{}> i mean they may overlap, but haskell isnt fp
15:02 <Cale> Well, if you manage to understand Haskell, you'll automatically pick up a bunch of functional programming principles.
15:02 <Cale> But yeah
15:02 <qu1j0t3> for{}: For an intro to haskell AND FP, Simon Thompson's "Haskell: The Craft of FP" is hard to beat imho
15:03 <for{}> qu1j0t3, thanks, ill look into it
15:03 Denthir joined
15:04 argent0 joined
15:05 <Cale> It's not a book, but I recommend this talk to a lot of people http://ulf.wiger.net/weblog/2008/02/29/simon-peyton-jones-composing-contracts-an-adventure-in-financial-engineering/
15:06 <Cale> It gives a general overview of a major theme of functional programming
15:08 takle joined
15:08 <Cale> Which is that in order to solve problems, we're never entirely satisfied with just solving problems directly (though a lot of that still gets done) -- what we really would like to do is to understand our space of problems well enough to build up a language for expressing them, and do this in such a way that the solutions to the problems can be recursively constructed from the descriptions.
15:09 <Cale> i.e. Make a little programming language, in which our specific problem is easy to express, and then the "interpreter" or "compiler" for the language will give us the solution.
15:10 <for{}> gtg, thanks
15:12 thc202 joined
15:13 moei joined
15:14 moei joined
15:15 peterbec` joined
15:17 cur8or joined
15:17 galderz joined
15:24 splanch joined
15:43 Denthir joined
15:44 grayjoc joined
15:47 <tdfirth> Hi all - I've been studying Haskell in my spare time for about 6 months now, really loving it after having something of a minor epiphany in the last few weeks (i.e., not everything is a total mystery anymore!)
15:47 <tdfirth> Have done a few smaller projects by myself
15:48 <tdfirth> but would love to have a crack at something a little larger - does anyone have any open source projects they think would be good for me to look into?
15:54 uglyfigurine joined
15:54 tom7942 joined
15:56 conal joined
15:57 splanch joined
16:05 tom7942 joined
16:08 Denthir joined
16:14 Denthir joined
16:16 peterbec` joined
16:17 hphuoc25 joined
16:32 mizu_no_oto_work joined
16:34 tom7942 joined
16:35 mcspud joined
16:36 andyhoang joined
16:37 argent0 joined
16:38 blissdev joined
16:41 Denthir joined
16:44 splanch joined
16:45 mizu_no_oto_work joined
16:49 <glguy> tdfirth: If you're interested in IRC enough to be on it and looking for Haskell projects to explore, there's my IRC client https://hackage.haskell.org/package/glirc https://github.com/glguy/irc-core
17:06 mcspud joined
17:06 expo873 joined
17:06 splanch joined
17:11 yellowj joined
17:13 peterbec` joined
17:17 grayjoc joined
17:29 NoCreativity joined
17:34 nil_ joined
17:37 splanch joined
17:39 hoffmeyer joined
17:40 hphuoc25 joined
17:49 snowcrshd joined
17:53 nacon joined
17:53 nacon joined
17:54 etrepum_ joined
17:54 edmoore_ joined
17:54 cmdv_ joined
17:54 joel135_ joined
17:55 ocharles_ joined
17:55 gluegadget_ joined
17:55 houli_ joined
17:56 rstone_ joined
17:56 numberte1 joined
17:56 pancro_ joined
17:57 kipd_ joined
17:58 mcspud joined
18:00 agates joined
18:00 cnr joined
18:00 QuantumLogic joined
18:00 domenkozar joined
18:02 monty joined
18:02 chlong joined
18:08 uglyfigurine joined
18:09 dni- joined
18:18 simendsjo joined
18:19 patbecich joined
18:20 Rodya_ joined
18:30 andyhoang joined
18:35 mac10688 joined
18:37 twopoint718 joined
18:38 malaclyps joined
18:42 for{} joined
18:43 <for{}> `data Polynom = Poly Float Float Float`: Poly is a type constructor or a data constructor? i found both names in different books
18:44 <for{}> i found 'value constructor' too
18:44 earldouglas joined
18:49 <yushyin> for{}: https://wiki.haskell.org/Constructor
18:49 <geekosaur> Polynom is the type constructor, Poly is the data constructor sometimes called value constructor
18:53 <for{}> thanks
18:56 ExpHP_ joined
18:56 vmeson joined
19:00 chlong joined
19:03 argent0 joined
19:04 albertus1 joined
19:06 peterbec` joined
19:10 emmanuel_erc joined
19:12 tapirus joined
19:13 raduom joined
19:14 mcspud joined
19:15 hoffmeyer joined
19:17 initiumdoeslinux joined
19:31 andyhoang joined
19:36 <for{}> can we consider the type constructor and the data constructor to be tags?
19:40 <benzrf> for{}: the type constructor? not really
19:40 <benzrf> the type constructor is a compile-time thing, so it doesn't make sense to talk about tags, which are a runtime implementation detail
19:40 <benzrf> imo
19:41 <monochrom> type constructor is not tag.
19:41 <monochrom> data constructor is.
19:42 <Cale> Maybe in some ways you could still consider type constructors a "tag", but it depends on what you mean by that word.
19:42 <monochrom> At least as far as how non-Haskell people interpret "tag".
19:43 <for{}> im still a non-haskell guy
19:43 <for{}> in the wiki it only says about the number of args
19:44 <for{}> it can have n args but it doesnt say what it is
19:44 <monochrom> Yes, there will be a time when a type is a tag too. You get a glimpse of it from some Java programs that use an empty interface for a type-level tag.
19:44 <for{}> im reading many books in parallel
19:44 <monochrom> n is up to you. Your Poly has n=3.
19:45 <for{}> of course
19:45 mengu joined
19:45 <for{}> i only wanted to emphasize it isnt specified what a type/data constructor **is**
19:46 <monochrom> Oh, you mean that.
19:47 <monochrom> This is why pronouns should be banned.
19:47 <benzrf> i mean, there's a lot of reasons
19:49 mengu joined
19:49 grayjoc joined
19:49 pbrant joined
19:49 <monochrom> There is no need to worry about type constructors (and no need to even use the "constructor" word) until you look at a type like "Maybe Int" and you wonder "what is the role of 'Maybe'?"
19:50 <monochrom> But data constructor is what you use to create values.
19:52 <monochrom> But eventually I don't care about "type constructor". It is not a useful classification.
19:52 <geekosaur> the data constructor is how haskell knows (a) at source level what type a value is (b) at runtime which constructor (e.g. Nothing vs. Just _) a value represents
19:53 splanch joined
19:55 runeks joined
19:55 sa1 joined
19:56 <monochrom> To a less extent, "function" is not a very useful classification either. But it is still lightly better than "type constructor".
19:57 dni- joined
19:58 Rodya_ joined
19:58 <Cale> Type constructor is a useful classification when it comes to understanding type class instances
19:59 <benzrf> tru
19:59 <monochrom> No. You need kind.
19:59 <Cale> Just as case expressions allow you to pattern match on data constructors, instance heads let you match on type constructors.
19:59 <monochrom> Either is a type constructor. Still doesn't tell you whether "instance Monad Either" is legal or not.
20:00 <Cale> oh, sure
20:00 <Cale> You *also* need to know about the kind, just as you'd need the types to match up in a case expression.
20:00 <monochrom> Similarly, "function" is not a very useful classification, on the ground that if I tell you "I have a function f" and conceal it's type, you still don't know whether "f True 3" is legal or not.
20:00 dni-_ joined
20:01 <Cale> instance MyClass (a b c)
20:01 <monochrom> "Either a" is not a type constructor, and yet "instance Monad (Either a)" is legal. Type-constructorness is informationless.
20:02 <Cale> Instances in Haskell 98 have to be for a type constructor applied to some number of distinct type variable arguments.
20:02 <monochrom> So informationless that even the converse question "Suppose 'instance Monad xxx' is legal, does this imply that xxx is a type constructor?" cannot be answered.
20:03 <monochrom> Sure, it has grammatical significance.
20:03 <Cale> It also matters when you get to talking about type families vs. data families
20:03 <monochrom> But you don't get a legal Haskell program just by satisfying its grammar.
20:03 <Cale> Type families are not type constructors.
20:04 <monochrom> Ah OK.
20:04 <Cale> and so you can't write instances for them in the same way as you can for data families and ordinary type constructors introduced with data
20:06 <monochrom> "function" is in a slightly better position because when I tell you "I have a function f" you can deduce what qualifies as its WHNF.
20:06 <for{}> type families are type classes?
20:08 <geekosaur> type families are type-level functions: you "invoke" them on a type, and get another type back
20:08 <geekosaur> type families are often associated with typeclasses
20:09 <for{}> i will find all about this by reading any book about haskell?
20:09 <geekosaur> no, because type failies are a ghc extension over standard Haskell. if you read a book which sticks to standard Haskell, it won't talk about type families
20:09 <geekosaur> it will talk about type vs. data constructors
20:10 <for{}> whats the best book about ghc?
20:11 <for{}> does an average haskell programmer know about type families?
20:12 <* geekosaur> has no idea what an "average haskell programmer" is...
20:13 <for{}> i want to understand the philosophy behind haskell
20:13 <for{}> ordinary then?
20:13 <for{}> im not a native english speaker
20:13 <Cale> for{}: Some will -- it's a feature that you often don't need to know about, but at some point it will become nice to add it to your set of options.
20:14 <geekosaur> not a problem with what you said, it's more a problem with me in this case :)
20:14 <geekosaur> but I'm not sure anyone has a good idea of what comprises an "average Haskell programmer"
20:14 <for{}> i didnt mean to offend anyone
20:14 <geekosaur> and yes, usually type families are someytthing behind the scenes in the implementation of a typeclass; but you may eventually find yourself needing them to solve a particular problem
20:15 <Cale> Yeah, I'm sort of lumping type families and class associated types together there.
20:15 <for{}> is there a book about "philosophy" behind haskell?
20:15 <geekosaur> you're not offending anyone, it's just that there's nobody collecting metrics on Haskell programmers to get an idea of what an "average Haskell programmer" is
20:15 <Cale> heh, SICP maybe? :D
20:15 poohflapz joined
20:15 Uniaika joined
20:16 <for{}> a link?
20:16 thc202 joined
20:16 <geekosaur> wadler's probably got some papers about it. probably also one of SPJ's retrospectives
20:16 <benzrf> sicp, really? o:
20:16 <Cale> That's halfway ironic because SICP is a book which uses scheme to teach its ideas
20:16 <benzrf> ah
20:16 <geekosaur> @google wearing the hair shirt
20:16 <lambdabot> http://www.dictionary.com/browse/hair--shirt
20:16 <lambdabot> Title: Hair shirt | Define Hair shirt at Dictionary.com
20:16 <geekosaur> bah
20:16 <geekosaur> @google wearing the hair shirt haskell
20:16 <lambdabot> https://www.microsoft.com/en-us/research/publication/wearing-hair-shirt-retrospective-haskell-2003/
20:17 <Cale> But if you look at all the ideas in SICP, you can see how Haskell was influenced by many of them
20:17 <Cale> https://sarabander.github.io/sicp/ -- here's a nice version of it
20:18 <geekosaur> ghc is a bit harder because it has a split philosophy; on the one hand it aims to be a practical production language, but on the other it's also at the forefront of type theory research
20:18 gothos joined
20:18 <Cale> But yeah, maybe papers like "Why functional programming matters"
20:18 <for{}> is there a sicp for haskell?
20:18 xificurC joined
20:19 <Cale> https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf
20:19 <for{}> an equivalent
20:19 <Cale> not really
20:19 <Cale> SICP is a rather unique book
20:19 <for{}> did you read it? just curious
20:19 <Cale> Yeah
20:19 <Cale> Quite a long while ago now
20:20 <for{}> would you reread it?
20:20 <Cale> I also watched the video lectures :)
20:20 <Cale> I'm not sure I'd spend the time re-reading it, but it was good.
20:20 tdfirth joined
20:20 <for{}> should i read miranda link?
20:20 <xificurC> I created a project with stack (stack new; stack setup). Then I added "QuickCheck" into test build-deps and ran stack test. Now I'm trying to import it in the generated test/Spec.hs file but with no luck...
20:21 <Cale> for{}: Yeah, it has some of the philosophy you might be after
20:21 <xificurC> was my setup correct and if so under what magical name can I import it?
20:21 <for{}> thanks, Cale
20:21 <kadoban> xificurC: What exactly did you try, and what was the exact error?
20:22 <benzrf> geekosaur: the forefront of type theory research?
20:22 <benzrf> its not even dependently typed...?
20:22 <kadoban> xificurC: Did you use the correct module name(s), usually something like Test.QuickCheck or Test.QuickCheck.Something
20:22 <xificurC> I tried to put "import QuickCheck" and "import Test.QuickCheck" at the top of the Spec.hs file
20:22 <geekosaur> not yet but there's a fair amount of work going toward "dependent Haskell"
20:22 <xificurC> the error is, ssec
20:22 <Cale> for{}: But then if you want to get serious about philosophy, you should look at the philosophy of mathematics behind type theory.
20:23 <geekosaur> and that's actually one of those forefronts; they want to figure out how to add dependent typing without breaking the type behavior people expect of Haskell
20:23 <xificurC> failed to load interface for Test.QuickCheck
20:23 <Cale> https://www.cs.cmu.edu/~crary/819-f09/Martin-Lof83.pdf
20:24 <kadoban> xificurC: Can you lpaste your whatever.cabal file? And maybe stack.yaml if there's anything interesting in there?
20:24 <for{}> Cale, thanks
20:24 <Cale> This is a paper which talks about logic and type theory, and well, it's got just slightly more philosophical babble than I usually would put up with, but in this case, the content is at least fairly reasonable :)
20:24 uglyfigurine joined
20:25 meandi joined
20:25 <Cale> Oh, from that alone, it might not immediately be obvious what the connection is to programming and type theory
20:25 <Cale> Wait, maybe there's something better by Martin-Löf I could link you
20:26 <Cale> (that one is good, but I just realised it doesn't actually get as far as talking about terms and types as opposed to simple propositions)
20:26 <xificurC> kadoban: I just solved it - Test.QuickCheck works but my editor (emacs with intero) needed a restart to catch the new package
20:26 <kadoban> I see, glad you figured it out.
20:26 <xificurC> kadoban: is there a simple, preferably command line way to find out what modules does a package hold?
20:26 <monochrom> Clearly, the best book for GHC is the GHC User's Guide.
20:27 <Cale> http://www.cse.chalmers.se/research/group/logic/book/book.pdf -- perhaps this, which is not by Martin-Löf, but is about using his type theory
20:27 <kadoban> xificurC: 'stack list-dependencies' probably
20:28 <Cale> ehh... I dunno
20:28 NeverDie joined
20:28 <Cale> Everything bothers me a little bit, where is the ideal resource I'm looking for? :)
20:28 <xificurC> kadoban: that shows me QuickCheck 2.9.2 but I wouldn't know what to import. Where should I find that I should import Test.QuickCheck and not QuickCheck or Foo.Bar?
20:29 <monochrom> Cale, I haven't written it, that's why. :)
20:29 <geekosaur> xificurC, likely you need to look up the package on hackage to see how to use it. packages are not modules
20:29 <monochrom> Lately I've been busy on www.vex.net/~trebla/haskell/cont.xhtml
20:29 <for{}> Cale, i downloaded all three pdfs
20:29 <kadoban> xificurC: The docs for QuickCheck. I usually look on stackage.org
20:30 <monochrom> However, I am skeptic about that Haskell's philosophy is type theory.
20:30 <xificurC> while that's not on the command line I'll take it, thank you
20:30 <geekosaur> type theory is part of it, not all of it
20:31 louispan joined
20:31 <for{}> Cale, if you have another suggestion, please call me using my nick
20:31 <monochrom> Not even that. Part of type theory is in part of Haskell's philosophy, yes. But you know what, that small part of type theory is merely Hindley-Milner type inference.
20:32 <Cale> for{}: anyway, modern functional programming is strongly influenced by type theory, which originated from ideas in the foundation of mathematics stemming back to the late 1920s and early 1930s with intuitionism, and then reworked extensively in the 60s and 70s by people such as Jean-Yves Girard, John Reynolds (those two are responsible for System F on which Haskell was originally founded), and Per Martin-Löf (who is
20:32 <Cale> responsible for one of the most well-regarded dependently type theories)
20:32 <Cale> dependent type theories*
20:33 <monochrom> Like if you said "complex analysis is behind the philosophy of integer addition" you would be technically right but it also would be a gross overstatement.
20:33 <Cale> Well, I say "Haskell", but obviously Haskell is more directly based on Miranda, which is also influenced by System F
20:33 <for{}> there are many books online and i want to learn as little as i can in order to fully understand haskell if possible
20:33 <benzrf> monochrom: heh
20:33 <benzrf> for{}: thats a terrible way of approaching it
20:33 <benzrf> focusing on the destination instead of the journey almost always produces crappy results when it comes to learning
20:33 <for{}> i cant read all the books about fp, benzrf
20:33 <benzrf> IMO
20:33 <Cale> for{}: Well, yeah, the stuff I'm giving you is not the short road to being good at writing programs in Haskell
20:33 <Cale> I'm just giving you historical and mathematical context
20:34 <for{}> Cale, there are probably tens of books about fp and its roots, i cant read them all, thats all im saying
20:34 <benzrf> thats true
20:34 <benzrf> personally i havent really read any books
20:34 <Cale> For being good at writing programs at Haskell, I would say monochrom's suggestion of the GHC user's guide is more practical than any of this :D
20:34 <benzrf> ive mostly just talked to people in irc and occasionally in person, written code semi-regularly, picked up libraries
20:34 <Cale> Yeah
20:35 <for{}> Cale, i feel i need to understand the philosophy behind
20:35 <benzrf> ive read a paper or two but not really anything super huge
20:35 <benzrf> for{}: i understand that drive, but i think in practice it usually ends up taking longer and being harder than something more breadth-first
20:35 <Cale> It's more fun to read papers containing really good examples of functional programming, rather than papers on the general philosophy of anything.
20:35 <benzrf> there's too high a level of connectivity in the graph, you'd end up having to backtrack all thje time
20:35 <for{}> i cant learn a language just by building projects in it
20:35 <benzrf> that's literally how you learn a language
20:36 <benzrf> :P
20:36 <Cale> There's a whole series of "Functional Pearls" pretty much all of which can be recommended
20:36 <monochrom> To be fair, I just recall that I was unfair to say it's merely HM type inference. There is also algebraic data types which is common to both type theory and Haskell. But again the contribution of type theory is castrated. Haskell certainly adopted the data constructor story, but also cut out the induction rule.
20:36 <dni-_> for{}: ofc you can
20:36 Pupnik joined
20:36 <for{}> Cale, i bookmarked
20:37 <benzrf> monochrom: "castrated" is kind of an ugly word for that >.>
20:37 <Cale> monochrom: Well, it didn't cut it out entirely -- it's just Haskell has general recursion, so you can write all the induction rules yourself :)
20:37 chlong joined
20:37 <benzrf> Cale: and also false
20:37 <for{}> dni-_, i need smth besides projects
20:37 <Cale> benzrf: hm?
20:37 <for{}> its just how my mind works
20:38 <Cale> benzrf: Okay, maybe I should say recursion principles instead :)
20:38 <monochrom> No, it's a bit stranger than that. The induction rule gives you restricted pattern matching, equivalently catamorphism. Haskell gives you arbitrary pattern matching.
20:38 <benzrf> monochrom: huh, what?
20:38 <monochrom> (But you can remind us of Lambek's lemma which just needs catamorphism to regain arbitrary pattern matching, at a time cost.)
20:38 <benzrf> for{}: yeah, ok, maybe im being a bit zealous
20:39 <benzrf> oh
20:39 <benzrf> heh
20:39 <monochrom> benzf, arbitrary pattern matching means you can do "case list of (x:xs) -> and you do what you please on xs".
20:40 <monochrom> Type theory does not allow that. Type theory says you can only do the same recursive call you have been doing on xs.
20:41 <benzrf> monochrom: oh, ok yeah i know about that
20:41 <Cale> for{}: Yeah, it's fair enough to dive into the surrounding material, I'm sure you'll eventually be interested in picking up some category theory as well, given that attitude. It's just, we tend to be a little hesitant about it, because from a practical standpoint, it's a big time sink relative to the expected usefulness -- unless you're generally interested in other areas of mathematics and such.
20:41 <benzrf> i just didn't think of it as a property of pattern matching per se
20:41 <benzrf> rather, of the body of a function
20:42 <monochrom> I could re-tell this by saying type theory does not offer pattern matching at all, it only offers foldr or catamorphism.
20:42 <Cale> I'm pretty sure you can incorporate rules for pattern matching directly into a type theory
20:42 AndreasK joined
20:42 <Cale> It's a little uncommon though
20:42 <monochrom> But it is more fun to re-word this as your-hands-tied pattern matching when comparing with Haskell.
20:43 <xificurC> `stack new` created a barebones project with a test file test/Spec.hs. Now I have a src/Intro.hs file and would like to test some functions from it with quickcheck. What would be the canonical way to do that? Should I pack everything into the one Spec.hs file? (there'll be more source files) If I create an e.g. IntroSpec.hs, how will `stack test` run it?
20:43 <Cale> The Calculus of Inductive Constructions that Coq is based on, I believe does that.
20:44 <Cale> -- it has logical rules for matching
20:44 peterbec` joined
20:46 NoCreativity joined
20:47 peterbec` joined
20:49 conal joined
20:51 <Cale> and of course, when you read papers about the way that GHC does type inference and checking, you'll find logical rules in the same style as they occur in type theory, but there will be a rule regarding case expressions.
20:52 <Cale> https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp-outsidein.pdf -- Figure 2 on page 13 here has a rule for case in a simple constraint-based type system :)
20:53 <Cale> It's not the prettiest thing in the world, and it's expressed a bit strangely for a logician
21:04 aarvar joined
21:05 <monochrom> Actually the whole idea of writing down type inference is going to be strange for a logician.
21:06 conal joined
21:06 <monochrom> Logicians write down rules for checking types or proofs. They enumerate what is legal, and implicitly everything else is illegal and known to be a priori.
21:07 <monochrom> But type inference is when you aren't sure yet, so its rules are going to be much more allowing, everything seems to be legal at first, but the catch is in the constraints generated.
21:10 grayjoc joined
21:10 splanch joined
21:16 <Cale> Well, type inference and type checking are kind of like reading the same logical rules in opposite directions :)
21:16 <Cale> (but you need syntax-directedness, which is a property that would be a strange thing for a logician to consider)
21:18 kori joined
21:18 <monochrom> Natural deduction is already syntax-directed, what with its introduction and elimination rules.
21:20 <monochrom> And then sequent calculus brings it to the next level, where you're also syntax-directed on both sides.
21:20 kori joined
21:20 tdfirth joined
21:23 Denthir joined
21:27 danny_ joined
21:28 t0by joined
21:33 andyhoang joined
21:34 sypwex joined
21:35 grayjoc joined
21:37 cur8or joined
21:37 <Akii> xificurC: you can just add new modules in test/ and use them in Spec.h
21:41 colt44 joined
21:43 hphuoc25 joined
21:44 <xificurC> Akii: do you have a good example project on github or other host where I could see an actual, basic setup? With more than 1 source file and more than 1 test file
21:45 <Akii> xificurC: it behaves like the stuff in src
21:46 <Akii> so you create a new module, import that inside Spec and add it to the other-modules section in the cabal file
21:46 <Akii> as far as I understood it, the whole test is the main function
21:46 <Akii> so whatever you include in there will be executed
21:49 <xificurC> Akii: so I tried this - created src/Intro.hs. Created test/IntroTest.hs which imports Intro. Added import IntroSpec into Spec.hs. Now `stack test` says "failed to load interface for Intro"
21:50 <xificurC> Akii: not sure what that means, if I made something bad with the imports, or Intro.hs wasn't compiled?
21:51 <Akii> xificurC: and your project compiles normally?
21:51 cur8or_ joined
21:51 <Akii> as in `stack build`
21:51 <Akii> because might be possible you forgot to include the module Intro to exposed-modules or smth
21:52 hiratara joined
21:53 <xificurC> Akii: I just created the file and added some functions, nothing more. I'm going through cis194 and want to keep it in 1 repository with tests and all
21:53 <xificurC> so Intro.hs is basically a standalone file that is Homework 1 of the course
21:53 <Akii> kay well I'm no expert but building should fail
21:53 <xificurC> but I wanted to have some tests for it in test
21:54 <Akii> and since the test suite depends on the library that probably won't work
21:55 <Akii> try adding `Intro` to your `exposed-modules` section of the library in the cabal file
21:56 <xificurC> Akii: that did it, thanks
21:56 <Akii> yay!
21:57 <xificurC> now, how can I get a quickcheck generator that generates Integers >0 ?
21:57 <Akii> that's where I'll quietly sneak out :D
21:57 <xificurC> reading through the docs I'm a bit lost where to start :)
21:57 <xificurC> haha
21:58 <Akii> http://stackoverflow.com/questions/39291494/only-generate-positive-integers-with-quickcheck
21:59 <Akii> what would I even do without Google
22:01 <xificurC> Akii: ooh, I just did that myself, cool
22:03 takle joined
22:06 NoCreativity joined
22:07 <xificurC> Akii: now if I have a bunch of test modules under test/ how should I update the .cabal file's test suite setup to run all of them?
22:08 takle joined
22:08 <Akii> you just import them in Spec and like run them inside this IO monad
22:10 <Akii> kinda depends on what testing framework you're using and what types there are
22:12 <xificurC> Akii: no framework :)
22:12 <Akii> like there is quickcheck, hspec, whatever, all combined
22:13 <Akii> all you need to do is to get it to compile; fun little task
22:13 <Akii> shouldn't be too hard
22:13 diminishedprime joined
22:13 <Akii> you can start by writing all your tests in one file then separating a working test
22:15 <xificurC> Akii: this is the cryptic (at least for me) output I get from `stack test` http://sprunge.us/VLIV
22:15 lpaste joined
22:15 cur8or joined
22:18 <xificurC> Akii: even if I use just the Spec.hs file it dies the same way :) my main calls a function which is IO () (basically it's a call to quickCheck ..arguments)
22:19 <Akii> does `stack build` work?
22:19 <xificurC> Akii: yes
22:20 <Akii> oh well, upload your code to github! :D
22:21 <xificurC> yeah, I'll need to do that next time, too late here
22:21 <Akii> I'll be here tomorrow, we can figure it out then
22:21 splanch joined
22:21 sigmundv_ joined
22:21 <Akii> it's probably a trivial thing
22:23 <xificurC> I don't know if I'll be here tomorrow, working family guy here :) But I'll surely get back to this
22:23 <xificurC> maybe I should really upload in case I get some time @work to look at this
22:25 <Akii> I'm always here xD
22:27 <xificurC> Akii: https://gitlab.com/xificurC/cis194/tree/master
22:28 louispan joined
22:30 sigmundv_ joined
22:31 hiratara joined
22:32 <xificurC> I'm off, night
22:33 <xificurC> and thanks
22:33 <Akii> np, cya!
22:35 andyhoang joined
22:37 zipper joined
22:38 tolt joined
22:44 louispan joined
22:49 argent0 joined
22:53 ederign joined
22:58 Prutheus joined
23:00 mcspud joined
23:04 buoto joined
23:11 louispan joined
23:18 dni- joined
23:21 eacameron joined
23:23 diminishedprime left
23:24 malaclyps joined
23:26 jathan joined
23:27 eacameron joined
23:38 conal joined
23:40 splanch joined
23:43 hphuoc25 joined
23:46 Denthir joined
23:54 animated joined
23:58 NoCreativity joined
23:59 sigmundv joined