Re:What are potential disadvantages of functional programming?
by surement on Thursday July 27, 2017 @08:02PM
(#14870886)
> 2. Use StateT and lenses. Your code can even look almost exactly like C if you want, with for and while loops with the same semantics as in C. I often use this when implementing heavily imperative papers in Haskell. It's still pure and everything, but looks just like an imperative language and performs well (if maybe not always full C speed).
I am no Haskell expert and that sounds quite interesting. Do you have any links to examples?
Re:What are potential disadvantages of functional programming?
by wyager on Thursday July 27, 2017 @08:41PM
(#14871036)
Shoot, I had some great example code from a few years ago but it was part of a uni assignment so the university made us take it off github.
Here's a fairly in-depth analysis of the approach: http://www.haskellforall.com/2013/05/program-imperatively-us...
The gist of it is that StateT gives you nice syntactic sugar around state-update functions of type `state -> (state, result)`.
Let's say your state type is like
data Boss = Boss {
health :: Int,
...
}
data Player = ...
data State = State {
boss :: Boss,
player :: Player,
...
}
boss.health -= 1
player.stats.score += 5
I'd say you have at least three fairly straightforward options.
1. Mechanically translate the loop to a recursive call. Not always idiomatic, but easy and pretty much guaranteed to compile to the same/similar assembly for a tight loop.
2. Use StateT and lenses. Your code can even look almost exactly like C if you want, with for and while loops with the same semantics as in C. I often use this when implementing heavily imperative papers in Haskell. It's still pure and everything, but looks just like an imperative language and performs well (if maybe not always full C speed).
3. If for some reason neither of those approaches work (e.g. If you're writing an algorithm that really benefits from mutation), you can use IO or ST for mutable variables. ST is really cool; it provides local mutability, but uses the type system to ensure that mutability never "escapes" into pure Haskell.