cocreature 2017-02-10 09:45:19
max3: so it looks like 0.5 switched from using fundeps to using type families
merijn 2017-02-10 09:48:52
Whee!
cocreature 2017-02-10 09:49:10
merijn: whuuu!
merijn 2017-02-10 09:49:20
I realised that, not only would it probably be easy to implement what I want. But I already have 90% of the code implemented in a package already :D
merijn 2017-02-10 09:50:51
GHC doesn't warn for non-exhaustive patterns in do notation?
merijn 2017-02-10 09:50:58
That's...pretty fucking awful
merijn 2017-02-10 09:52:30
I don't suppose there's a way to fix that? Or does GHC8 perchance have that?
pikajude 2017-02-10 09:52:34
no, because of fail
merijn 2017-02-10 09:52:51
Yet another reason to hate fail
merijn 2017-02-10 09:54:22
I was planning to rely on warnings to find all places to change things :(
dolio 2017-02-10 09:54:58
If you turn on -XMonadFailDesugaring, it will have a different type.
merijn 2017-02-10 09:56:27
dolio: That just infers a MonadFail constraint, no?
dolio 2017-02-10 09:56:42
Yes, that is a different type.
merijn 2017-02-10 09:56:55
dolio: Except I have a fixed monad (IO)
merijn 2017-02-10 09:57:09
So, since I'm assuming that has a MonadFail instance it doesn't actually help me here
dolio 2017-02-10 09:57:15
Ah.
pikajude 2017-02-10 09:57:42
it does have a MonadFail instance
merijn 2017-02-10 09:57:45
I guess I'll have to use grep...like a savage
dolio 2017-02-10 10:02:36
It sounds like -Wincomplete-uni-patterns should warn about this, but it seems like it doesn't.
merijn 2017-02-10 10:03:25
dolio: ok, then I don't have to bother upgrading GHC either :p
ClaudiusMaximus 2017-02-10 10:10:59
merijn: one possibly-insane-amount-of-work way might be make an newtype over IO with Monad but no MonadFail instance? maybe a MonadIO instance could help too? (especially if you can find MonadIO m => versions for your primitive IO actions)
merijn 2017-02-10 10:11:29
ClaudiusMaximus: That'd like quadruple the code I have :p
ClaudiusMaximus 2017-02-10 10:11:55
ok, then grepping for <- might do
merijn 2017-02-10 10:12:11
ClaudiusMaximus: Or just the specific constructor I'm expanding :)
ClaudiusMaximus 2017-02-10 10:12:21
that too
drostie 2017-02-10 10:28:48
So the normal ListT done right is newtype ListT m x = ListT { runListT :: m (Maybe (x, ListT m x)) }. I have a desire for streams like this in JS but the newtypes and returns are creating tons of allocations, slowing the code down bigly.
ryantrinkle 2017-02-10 10:29:08
is there something like bytestring-trie, but for Text?
drostie 2017-02-10 10:31:10
It seems like the obvious thing to do is to replace (x, ListT m x) with (Array Int x, ListT m x) so that I can skip the allocations for these sorts of tasks, but then I hypothetically want to move the pair constructor outside of the maybe as well, newtype ListT m x = ListT { runListT :: m (Array Int x, Maybe (ListT m x)) }. In either case you then get that the original ListT is only isomorphic to a certain equivalence class of the
drostie 2017-02-10 10:31:10
new ListTs.
drostie 2017-02-10 10:32:27
So I guess my question to you guys is "Is that a really bad idea and I'm just not realizing it?" or so.
drostie 2017-02-10 10:34:03
(The equivalence class is basically [[1,2], [3,4], [5,6]] being equivalent to [[1,2,3], [4,5,6], []] in the identity monad.)
monochrom 2017-02-10 10:37:02
No, don't go (Array Int x, Maybe (ListT m x)). In the case of Nothing, now you still have to provide a fictitious array, and the user has so many more cases to worry about.
drostie 2017-02-10 10:38:01
Cases?
monochrom 2017-02-10 10:38:23
Think about what the user has to go through.
drostie 2017-02-10 10:38:38
Yes, I do have to allocate an empty array to return ([], None) for the empty array.
drostie 2017-02-10 10:38:47
er, empty ListT.
merijn 2017-02-10 10:42:30
So...some advice: Suppose I have two variants of a function that's say, 2-4 lines of code, extract into generic version and write the special cases in terms of the generic one or just duplicate the code?
benzrf 2017-02-10 10:43:07
depends on context probly
drostie 2017-02-10 10:43:28
monochrom: oh, maybe I see what you're saying. I think you're saying that it's conceptually more complicated to have to process []
monochrom 2017-02-10 10:43:37
If the first option is not slower, do it, and write comments to explain.
drostie 2017-02-10 10:43:54
I mean, if it occurs in the middle of the ListT.
merijn 2017-02-10 10:43:59
The context is: it's a particularly tricky 2-4 lines of concurrent code, but the generic version doesn't cleanly fall out
monochrom 2017-02-10 10:44:17
So write comments to explain.
monochrom 2017-02-10 10:44:35
Write the whole bloody derivation proof in comments. That's what comments are for.
monochrom 2017-02-10 10:44:54
Comments should be for explaining to humans. Not explaining to the computer "don't compile this code".
