ph88_ 2017-01-29 06:48:04
ok i'm a bit surprised, i have a file about 4K lines with some comments in between, i run time stack build --ghc-options '-O0 -j4 -Rghc-timing' and my core i7 920 runs already an hour on this !!
ph88_ 2017-01-29 06:48:54
using 8GB of memory, but i have 24GB so depending on the statistics i will set it to use more on next run
ph88_ 2017-01-29 06:49:01
but this is the slowest compiler i ever saw o_O
Tuplanolla 2017-01-29 06:52:25
Sounds like a GHC bug, ph88.
monochrom 2017-01-29 06:52:56
4k is on the unusually big side for a Haskell module. Not to say that I know how fast GHC is for this.
MarcelineVQ 2017-01-29 06:53:06
with that kind of memory use I'd also be suspect of extensions you may have enabled, some of the type-fu-checking can get exponential
monochrom 2017-01-29 06:53:56
Actually Haskell 2010 type inference is already exponential.
MarcelineVQ 2017-01-29 06:54:03
:>
monochrom 2017-01-29 06:54:34
In fact going all the way back to plain Milner-Robin, it is still exponential.
ph88_ 2017-01-29 06:54:46
https://paste.fedoraproject.org/539939/85712480/ i use these extensions
monochrom 2017-01-29 06:55:08
Err, Hindley-Milner!
Lokathor 2017-01-29 06:55:52
ph88_, you name shadower!
ph88_ 2017-01-29 06:56:19
oh oh
MarcelineVQ 2017-01-29 06:57:37
I'd be looking at that UndecidableInstances first of all
ph88_ 2017-01-29 06:57:51
ye actually i think i left that in without reasons
MarcelineVQ 2017-01-29 07:00:13
type families can also blow up in some cases, idk which though: https://ghc.haskell.org/trac/ghc/ticket/8095
ph88 2017-01-29 07:00:18
oh it's there for a reason alright .. but perhaps there is another way to solve it
xcmw 2017-01-29 07:01:56
> (+) <$> [1,2,3] <*> [4,5,6]
ph88 2017-01-29 07:01:57
MarcelineVQ, if i dont' use UndecidableInstances i get a lot of these errors: https://paste.fedoraproject.org/539950/14857128/
MarcelineVQ 2017-01-29 07:01:57
Before chasing too many rabbits though I'd suggest just breaking up your code into at least 3 or 4 modules instead of one 4k file
lambdabot 2017-01-29 07:01:59
[5,6,7,6,7,8,7,8,9]
xcmw 2017-01-29 07:02:29
Why is it not [5,7,9]?
hpc 2017-01-29 07:03:33
xcmw: what you're looking for is ZipList
monochrom 2017-01-29 07:04:00
[]'s <*> has to be consistent with >>= in doing cartesian product.
xcmw 2017-01-29 07:04:21
hpc: Thank you
cocreature 2017-01-29 07:06:35
ph88: doing some sort of binary search by removing half of your definitions/replacing them with undefined, can often help finding the problematic definition
xcmw 2017-01-29 07:06:45
Why doesn't ZipList work with do notation?
ertes 2017-01-29 07:06:49
xcmw: use zipWith
hpc 2017-01-29 07:06:56
because it can't satisfy the Monad laws
ertes 2017-01-29 07:07:15
even if it could, it would be horribly inefficient
monochrom 2017-01-29 07:07:27
ZipList fails to be a monad.
ertes 2017-01-29 07:07:32
xcmw: you can use do-notation with ZipList, if you enable -XApplicativeDo
monochrom 2017-01-29 07:09:16
Mathematics conspires to put you between a rock and a hard place.
xcmw 2017-01-29 07:09:18
Stupid question: Can't you just make (ZipList as) >>= f = ZipList $ as & map f & LI.imap (\index (ZipList element) -> element !! index)
ertes 2017-01-29 07:09:43
xcmw: that violates the monad laws and also explains why "it would be horribly inefficient" =)
xcmw 2017-01-29 07:10:09
ertes: Ok, Thanks
hpc 2017-01-29 07:10:12
xcmw: it's actually a good exercise to work out for yourself how it breaks the laws
ertes 2017-01-29 07:10:43
xcmw: there is a family of fixed-length zip-lists, each an individual monad (including the infinite one), and each with the same terrible (>>=) performance
ertes 2017-01-29 07:11:32
for example this one is a monad: data V3 a = V3 a a a
ertes 2017-01-29 07:11:47
also V4, V5, V1000 and in the limit ZipStream
xcmw 2017-01-29 07:13:13
ertes: Ok
Zemyla 2017-01-29 07:16:53
I wish I could remember what my mind was like before and while I was getting good at Haskell.
Zemyla 2017-01-29 07:18:21
Like, how I went from "What's a monad?" to "I can build a monad, in a cave, with a box of scraps!"
ph88_ 2017-01-29 07:19:32
cocreature, i commented like 99% of the code and i left this little snippet of code in https://paste.fedoraproject.org/539980/13891148/ which causes the undecidable instance. Why is this happening ?
ph88_ 2017-01-29 07:20:17
by the way, if i newtype ContextItem it also happens newtype ContextItem = Foo String
cocreature 2017-01-29 07:22:57
ph88_: I was more thinking about commenting to find out which part causes GHC's compile times to blow up. UndecidableInstances can cause problems but there are also valid usecases
ph88_ 2017-01-29 07:23:42
ok i will try to comment with UndecidableInstances .. but actually i still like to get rid of UndecidableInstances !
cocreature 2017-01-29 07:23:45
ph88_: the problem is that to check if something satisfies Rule f DesignUnit, ghc has to check whether it satisfies Rule f ContextClause.
cocreature 2017-01-29 07:23:50
ph88_: but none of these terms is smaller
cocreature 2017-01-29 07:23:56
so there could be an infinite recursion
ph88_ 2017-01-29 07:24:37
what something ?
cocreature 2017-01-29 07:25:00
ph88_: so let's say you use "get" somewhere
cocreature 2017-01-29 07:25:23
GHC then has to satisfy some constraint because "get" is a class method
cocreature 2017-01-29 07:25:43
so to check whether the constraint is satisfied it has to check all instances
ph88_ 2017-01-29 07:26:04
which constraint are you talking about ?
cocreature 2017-01-29 07:26:12
ph88_: basically the problem that you could write "instance Rule f ContextItem => Rule f ContextClause where" and "instance Rule f ContextClause => Rule f ContextItem where"
cocreature 2017-01-29 07:26:18
so then GHC would keep looping
ph88_ 2017-01-29 07:26:33
o_O
ertes 2017-01-29 07:26:40
Zemyla: i miss the kind of epiphanies i used to have in the first year =)
ertes 2017-01-29 07:27:00
it was like exploring a parallel universe completely unknown to most people
ph88_ 2017-01-29 07:27:15
i was just reading that as for there to be "Rule f ContextItem" there must exist "Rule f ContextClause" which is really easy to check
cocreature 2017-01-29 07:28:08
ph88_: it's more like: Rule f ContextClause _implies_ Rule f ContextItem
cocreature 2017-01-29 07:28:25
ph88_: but how do you know if Rule f ContextItem is true? you have to check again
cocreature 2017-01-29 07:28:40
ph88_: and if you construct a cycle of these dependencies, GHC loops forever
ph88_ 2017-01-29 07:28:53
i don't see how this is cyclic ..
cocreature 2017-01-29 07:29:20
codedmart: consider "instance Rule f ContextItem => Rule f ContextClause" and "instance Rule f ContextClause => Rule f ContextItem"
cocreature 2017-01-29 07:29:25
eh ^ ph88_
ph88_ 2017-01-29 07:29:37
line 14 this code Rule f ContextItem => is not in the source file, so it should give an error and abort
ph88_ 2017-01-29 07:30:21
ok if you use "instance Rule f ContextClause => Rule f ContextItem" i totally see how that is cyclic .. but that is not in the code
cocreature 2017-01-29 07:30:42
ph88_: instances can come from other files. so GHC has to conservatively reject instances assuming there _could_ be one that created a cycle. this does not mean that there actually is one
cocreature 2017-01-29 07:30:57
which is why enabling UndecidableInstances is completely fine in a lot of cases
ph88_ 2017-01-29 07:31:09
how can i protect my classes in my module so that it doesn't go search for instances in other modules ?
cocreature 2017-01-29 07:31:16
you can't
cocreature 2017-01-29 07:31:23
well you can not export the class
cocreature 2017-01-29 07:31:27
then people can't make instances
ph88_ 2017-01-29 07:31:47
the module i use is just the main module .. it's for an executable not a package
cocreature 2017-01-29 07:32:12
ph88_: all that UndecidableInstances does is that it's now your job to make sure that there are no cycles. GHC doesn't try to check it
ph88_ 2017-01-29 07:32:47
i feel like i should write them in a dedicable way so i can keep the ghc check in
ph88_ 2017-01-29 07:33:00
i just don't get how that code is undecidable :/
ph88 2017-01-29 07:37:40
cocreature, i'm gonna explore that different path and just add code until compile times blow up
monochrom 2017-01-29 07:38:07
No, use the subtraction method.
ertes 2017-01-29 07:39:18
why are so many modules not linked in ?
ertes 2017-01-29 07:39:24
i need the documentation for GHC.STRef
ph88 2017-01-29 07:40:36
monochrom, you think it's not better to start small with something that works ?
monochrom 2017-01-29 07:40:39
Perhaps the module isn't exposed to begin with?
ertes 2017-01-29 07:40:51
monochrom: i can import it
monochrom 2017-01-29 07:41:02
Ah, strange, I don't know.
ertes 2017-01-29 07:41:04
anyway, the proper way to add a finaliser to an STRef is to add it using 'addFinalizer' on the underlying MutVar#, right?
ertes 2017-01-29 07:41:18
not on the STRef itself
ertes 2017-01-29 07:41:36
data STRef s a = STRef (MutVar# s a) -- here is how STRef is defined
monochrom 2017-01-29 07:41:38
ph88, you currently don't have a small working thing to add to. You currently have a big questionable thing.
monochrom 2017-01-29 07:42:41
Recall the story of Ptolemy's epicycles.
vimalloc_ 2017-01-29 07:43:31
I'm new to haskell, and am working my way through some excersises and exaples. I've got this code, which I cannot get to compile, but I'm having a hard time figuring out what is wrong with it. Would anyone mind taking a look? https://gist.github.com/vimalloc/b17a6ac578328a714280d9c5ad00d0f8
