Cale 2017-03-07 22:46:31
So try something like toSElem x = SM $ Map.fromList [("name", STR $ name x), ("children", STR $ "lol")]
biglama 2017-03-07 22:46:44
So brynedwards is right, I should instantiate StringTemplateShows instead ?
Cale 2017-03-07 22:46:44
and I think you can leave out the toSElemList
Cale 2017-03-07 22:46:54
The default instance for that should do
biglama 2017-03-07 22:59:07
my configurations files are in the INI format
Cale 2017-03-07 22:59:40
Unhammer: hehe, I just feel that whenever someone uses the word "performant" it's because they haven't actually done enough work to justify whatever claim it is that they're about to make -- otherwise they'd talk directly about what kind of performance they meant
Unhammer 2017-03-07 23:02:12
Cale, yeah … I haven't done any work to measure :) I just got a suggestion from hlint, and started wondering if that was a "pure style" thing, or there were some deeper reason.
Cale 2017-03-07 23:02:40
It will use less time because it does fewer allocations.
Cale 2017-03-07 23:02:59
It may use slightly less space, but not significantly less, in isolation.
Cale 2017-03-07 23:04:09
(because the cons cells of the intermediate list will immediately become garbage the moment they're created)
Unhammer 2017-03-07 23:04:23
Even without measuring, experienced coders do kind of write more performant code "by default", pattern-matching on previous experiences or whatnot. My early emacs-lisp was full of tail-recursion because I simply didn't know that .el doesn't TCO, now I'd never think about doing that without good reason.
SpinTensor 2017-03-07 23:05:24
Hi, started learning Haskell. As exercise i wanted to rewrite the elem function. I get a compile error and I don't know why: http://pastebin.com/c6jJpQnh
spatial_ 2017-03-07 23:05:34
do val <- value a index return ( BoardState xloc oloc index) val is an IO Int. So there is an error.
Cale 2017-03-07 23:05:45
"Tail calls" are kind of a weird thing in Haskell as well. There's no need for tail call optimisation because there's nothing which really corresponds to an ordinary call stack to begin with.
Cale 2017-03-07 23:05:55
(at least in GHC)
SpinTensor 2017-03-07 23:06:08
(n==x) returns a bool, so why does the compiler want a type (Eq a) somewhere?
Cale 2017-03-07 23:09:34
You're constructing an IO action which, when executed, is going to give a BoardState
mniip 2017-03-07 23:09:43
SpinTensor, what are the types of n and x
Cale 2017-03-07 23:09:49
So this has type IOArray Int Int -> BoardState -> IO BoardState
spatial_ 2017-03-07 23:10:05
Intention was to get Int from val which is IO Int and use it
Cale 2017-03-07 23:10:09
If you want to read an IOArray, you'll need to be executing an IO action, you can't do that elsewhere.
mniip 2017-03-07 23:10:37
SpinTensor, you're saying that elem' can be applied to a value of any type and a list of values of that type
Cale 2017-03-07 23:10:39
Where's the definition of value?
mniip 2017-03-07 23:11:01
SpinTensor, and then you proceed to use == on those types, but == doesn't work on all types
spatial_ 2017-03-07 23:11:07
value :: ( IOArray Int Int) -> Int -> IO Int value a index = liftIO (runReaderT (readvalue index ) a)
mniip 2017-03-07 23:11:10
only those that are Eq, hence the type error
SpinTensor 2017-03-07 23:11:12
it should not matter what they are, right?
Cale 2017-03-07 23:11:18
mniip: thanks for answering SpinTensor's question btw :)
mniip 2017-03-07 23:11:47
SpinTensor, of course it does matter
mniip 2017-03-07 23:11:51
not all types can be =='d
SpinTensor 2017-03-07 23:11:59
mniip: oh. so I need to write elem' for specific types when using pattern matching?
Cale 2017-03-07 23:12:01
spatial_: whaaaaa
mniip 2017-03-07 23:13:03
SpinTensor, no
mniip 2017-03-07 23:13:03
SpinTensor, you just have to specify that 'a' in your type signature should be a type that supports being =='d
Cale 2017-03-07 23:13:03
spatial_: Are you sure you don't just want value = readArray ?
mniip 2017-03-07 23:13:03
see:
mniip 2017-03-07 23:13:03
:t (==)
SpinTensor 2017-03-07 23:13:03
mniip: how do i do that?
lambdabot 2017-03-07 23:13:03
Eq a => a -> a -> Bool
Cale 2017-03-07 23:13:03
spatial_: What's the ReaderT shenanigans about?
mniip 2017-03-07 23:13:14
that 'Eq a' is telling you that 'a' should be an instance of Eq in order to use ==
Cale 2017-03-07 23:14:22
and that liftIO is definitely unnecessary and does nothing
spatial_ 2017-03-07 23:28:05
So I need to move all these smaller functions into a larger one.
spatial_ 2017-03-07 23:28:32
And manage it
Cale 2017-03-07 23:28:40
spatial_: You don't necessarily have to -- IO actions can be broken up into smaller parts as well if you like
mniip 2017-03-07 23:28:47
MVector sounds cool
mniip 2017-03-07 23:28:51
looks like it works with ST
Cale 2017-03-07 23:28:53
But perhaps start with a big lump of code and decide how to carve it up later
mniip 2017-03-07 23:28:57
which is a nice thing in this context
Cale 2017-03-07 23:29:25
Oh, and yeah, there's STArray if you want to compute something using mutable arrays and end up with a pure function in the end.
Cale 2017-03-07 23:29:41
But stick with IOArray for the time being until you get the hang of that
mniip 2017-03-07 23:29:44
STArray is eh
mniip 2017-03-07 23:29:54
I was more hinting at STVector
Cale 2017-03-07 23:30:01
Well, it's similar
kuribas 2017-03-07 23:46:32
I tested this: https://www.reddit.com/r/haskell/comments/1rcc8t/performance_of_the_st_monad_over_the_state_monad/
kuribas 2017-03-07 23:46:32
I get the same performance, the St monad being slightly slower.
