glguy 2017-01-27 10:45:14
sometimes
davean 2017-01-27 10:45:22
a -> list -> of -> values -> it -> takes -> theTypeItMakes
geekosaur 2017-01-27 10:45:30
:t Just
lambdabot 2017-01-27 10:45:32
a -> Maybe a
glguy 2017-01-27 10:45:33
:t True
lambdabot 2017-01-27 10:45:35
Bool
geekosaur 2017-01-27 10:46:05
in some ways, GADT syntax may be a better way to get to understand this
davean 2017-01-27 10:46:19
geekosaur: in probably all ways :)
ph88 2017-01-27 10:47:18
i think <- is like unpack lol
davean 2017-01-27 10:47:50
ph88: that will probably do you fine
mohsen_ 2017-01-27 10:48:06
Hi
mohsen_ 2017-01-27 10:48:19
Why does this happen: https://ptpb.pw/5u6m ?
davean 2017-01-27 10:48:39
ph88: just be willing to revisit your intuitions when you come upon something deeply novel
glguy 2017-01-27 10:48:50
mohsen_: Because you provided a type signature but no implementation of sum'
mohsen_ 2017-01-27 10:49:14
glguy: Do I have to provide the implementation first?
glguy 2017-01-27 10:49:24
mohsen_: No, you'll have to provide it at the same time
glguy 2017-01-27 10:49:35
mohsen_: A GHCi session isn't like typing in a .hs file one line at a time
davean 2017-01-27 10:49:41
(this is something that probably doesn't help ghci's usability)
geekosaur 2017-01-27 10:49:42
you need to provide them together, separated by a semicolon. in ghc versions before 8.0.1 you must also prefix with "let"
ph88 2017-01-27 10:49:48
davean, is my thinking ok when i start doing something like this https://paste.fedoraproject.org/537877/53764148/ so i leave out the return as you suggest ?
glguy 2017-01-27 10:49:50
sum' :: Num a => a -> a; sum' = sum
geekosaur 2017-01-27 10:50:28
(I am thinking that error looks like a version that needs "let" and is therefore parsing that as a type ascription on an undefined name)
glguy 2017-01-27 10:50:30
mohsen_: GHCi is better used where you put all your definitions in a file, load that with GHCi, and then experiment with one-off expressions in GHCi using those definitions
davean 2017-01-27 10:50:43
ph88: I expect you want to fmap that fromMaybe, whcih you can do nicely with <$>
ph88 2017-01-27 10:51:05
mohsen_, there is an option to set multiline in ghci (i can recommend it, it's useful) and for implementation you can do sum' = undefined if you don't want to think about the implementation yet
ph88 2017-01-27 10:51:57
davean, like this ? fromMaybe "" <$> o $ do
davean 2017-01-27 10:52:15
yes, with the appropriate parentheses to make order of operation happy
mohsen_ 2017-01-27 10:52:46
Thanks guys
ph88 2017-01-27 10:55:04
davean, i think fmap is nicer here, what you think ? https://paste.fedoraproject.org/537881/14855540/
davean 2017-01-27 10:55:29
ph88: entirely personal style
ph88 2017-01-27 10:55:41
ok i really have to get use to this that i don't have to use return in the do-block
davean 2017-01-27 10:56:04
I mean, you can use it if you like it :)
orzo 2017-01-27 10:56:11
seems my memory leaks are all gone
ph88 2017-01-27 10:56:28
do i even need the do on line 24 anymore ?
davean 2017-01-27 10:56:37
ph88: of course not :)
ph88 2017-01-27 10:56:41
o_O
davean 2017-01-27 10:57:09
ph88: You have training wheels you didn't even know you had :)
ph88 2017-01-27 10:58:37
i think i should make a function like this \x -> fmap (fromMaybe "") x because i notice i use this pattern quite a lot
orzo 2017-01-27 10:58:43
when did you need the do
ph88 2017-01-27 10:59:01
orzo, when you want to work with <-
orzo 2017-01-27 10:59:20
i mean on line 24
orzo 2017-01-27 10:59:31
you have a do on 25 to work with <-
orzo 2017-01-27 11:00:13
i guess maybe at some point you didn't have the fmap (fromMaybe ..) bit
ph88 2017-01-27 11:00:25
orzo, before the code was like at line 2 .. that's where the do come from .. this is all different versions of the same code
zennist 2017-01-27 11:00:48
why is State not a Monoid?
zennist 2017-01-27 11:01:08
(->) a b is a Monoid if b is a monoid
orzo 2017-01-27 11:01:15
does using "return" force "Monad" over "Applicative" ?
zennist 2017-01-27 11:01:35
I suppose we can make State a monoid simply by running the two State funcs and mappending the resultant valus
ph88 2017-01-27 11:01:44
orzo, yes i think so, for applicative you can use pure .. but stick around maybe someone can give you a better answer because i'm just a beginner myself
orzo 2017-01-27 11:01:59
that's a shame
Tuplanolla 2017-01-27 11:02:06
That's all, ph88.
ph88 2017-01-27 11:02:10
@src return
lambdabot 2017-01-27 11:02:10
Source not found. Just try something else.
ph88 2017-01-27 11:02:14
@src pure
lambdabot 2017-01-27 11:02:14
Source not found. Your mind just hasn't been the same since the electro-shock, has it?
ph88 2017-01-27 11:02:30
Tuplanolla, ?
zennist 2017-01-27 11:02:49
anyone who can answer my Monoid question?
glguy 2017-01-27 11:03:12
zennist: It doesn't have an instance because the author decided not to provide one
orzo 2017-01-27 11:03:23
i know return is technically a memeber of Monad, but they could have a rewrite rule to make it pure and deprecate it
zennist 2017-01-27 11:03:34
is that deliberate - or simply not thought out?
zennist 2017-01-27 11:04:36
i can see this being quite useful though - now, as soon as you want a state, you have to run it as Applicative for accumulation; with Monoid instance you just need a foldMap
geekosaur 2017-01-27 11:05:33
zennist, Monoid is kind *, MonadState and instances thereof are kind * -> *
glguy 2017-01-27 11:05:46
It wouldn't involve MonadState
glguy 2017-01-27 11:05:55
instance (Monad m, Monoid a) => Monoid (StateT s m a) where mempty = return mempty; mappend = liftA2 mappend
orzo 2017-01-27 11:06:37
zennist: couldn't you just fold over (*>) instead of (<>) ?
orzo 2017-01-27 11:18:09
if you use Data.Map.Lazy in a TVar for a mutable key-value table, is it pretty much impossible to not leak?
orzo 2017-01-27 11:19:44
I wasn't patient/careful enough to verify each individual change in isolation was a leak fix, but one thing i did is switched from PSQueue to psqueues inside of a TVar
orzo 2017-01-27 11:20:28
because PSQueue doesn't have !s on it's constructor arguments, I figured it was being too lazy
monochrom 2017-01-27 11:24:08
Data.Map.Strict leaks less.
monochrom 2017-01-27 11:24:38
There is a way you can stay with Data.Map.Lazy and not leak, but what you do will be what Data.Map.Strict does.
orzo 2017-01-27 11:25:57
would you have to add a lookup immediately following any insert?
monochrom 2017-01-27 11:27:01
No. But seq the insert.
orzo 2017-01-27 11:28:05
that's specific to Data.Map ?
orzo 2017-01-27 11:28:32
seems to me if all i know is that it's a lookup table, i need to use a lookup to force all the wobly bits after an insert
monochrom 2017-01-27 11:30:17
I don't know how to answer that question.
orzo 2017-01-27 11:31:38
well seq can only force the values you are putting in, i don't see why it would force the spine
monochrom 2017-01-27 11:32:27
But if it's Data.Map, you do know that seq triggers forcing the spine.
monochrom 2017-01-27 11:33:12
It is "not specific" to Data.Map because Data.Set and Data.HashSet and Data.HashedMap and a million other things do this too.
monochrom 2017-01-27 11:33:48
But it is "specific" to Data.Map because you have to know it's Data.Map (or Data.Set, or Data.HashedMap, or...)
orzo 2017-01-27 11:34:22
what about PSQueue ?
monochrom 2017-01-27 11:34:32
See what's the problem? You have an assumption that says "I am encountering an abstract data type, so abstract that I absolutely, honestly, truly know nothing whatsoever"
orzo 2017-01-27 11:34:54
well i actually don't know
orzo 2017-01-27 11:35:06
i've not read how Data.Map works
monochrom 2017-01-27 11:35:08
But that is an unrealistic assumption. You always know enough. Sometimes from the doc, sometimes from the source code, sometimes from hearsay from #haskell.
orzo 2017-01-27 11:40:59
Data.Map puts !s in it's constructors, but { data PSQ k p = Void | Winner k p (LTree k p) k } does not. Am I write to suspect and avoid using PSQueue in a TVar?
orzo 2017-01-27 11:41:12
s/write/right/
monochrom 2017-01-27 11:41:36
Is there any reason this is specific to TVar?
orzo 2017-01-27 11:41:49
hmm. LTree uses !s
monochrom 2017-01-27 11:42:16
I can simply answer "yes". But then the logical conclusion is that you won't even put a list in a TVar.
orzo 2017-01-27 11:42:16
TVar, IORef, ...
monochrom 2017-01-27 11:42:34
And yet TChan did just that. In fact probably worse than that.
orzo 2017-01-27 11:43:22
LTree uses ! on everything except recursive instances of LTree
monochrom 2017-01-27 11:43:46
TChan is a "lazy" tuple of two "lazy" lists in a TVar. It is so going to leak.
orzo 2017-01-27 11:44:05
are you being sarcastic
monochrom 2017-01-27 11:44:21
First sentence? Second sentence?
orzo 2017-01-27 11:44:44
i don't have a problem with lists
orzo 2017-01-27 11:45:05
but i want to be able to try out different lookup tables without having to read all their code and figure out exactly how they work
monochrom 2017-01-27 11:45:07
Why? They're as lazy as any other un!ed ADT.
