How do I modify a variable in Haskell?

[jamesbrock]

Mr. Burge has written a nicely thought-out blog post showing an evolution of different ideas about how to write to an array in Haskell.

I don't want people trying to follow the evolution to get the impression that iterating and writing to an array is really hard in Haskell, so here is a complete Haskell program which

1. Initializes a 10x10 mutable array to 0.

2. Iterates in a for-loop from 0 to 9, setting the diagonal to 1.

3. Freezes the mutable array to an immutable array and prints it.

  module Main where
  
  import Foreign.C.Types (CInt)
  import Control.Monad (forM_)
  import Numeric.LinearAlgebra (toLists) -- http://hackage.haskell.org/package/hmatrix-0.18.1.0/docs/Numeric-LinearAlgebra-Data.html
  import Numeric.LinearAlgebra.Devel (runSTMatrix, newMatrix, writeMatrix) -- http://hackage.haskell.org/package/hmatrix-0.18.1.0/docs/Numeric-LinearAlgebra-Devel.html
  
  main = do
      putStrLn $ unlines $ fmap unwords $ fmap (fmap show) $ toLists aImmutable
    where
      aImmutable = runSTMatrix $ do
          a <- newMatrix (0::CInt) 10 10
          forM_ [0..9] $ \i -> writeMatrix a i i 1
          return a

Output:

  1 0 0 0 0 0 0 0 0 0
  0 1 0 0 0 0 0 0 0 0
  0 0 1 0 0 0 0 0 0 0
  0 0 0 1 0 0 0 0 0 0
  0 0 0 0 1 0 0 0 0 0
  0 0 0 0 0 1 0 0 0 0
  0 0 0 0 0 0 1 0 0 0
  0 0 0 0 0 0 0 1 0 0
  0 0 0 0 0 0 0 0 1 0
  0 0 0 0 0 0 0 0 0 1

[jordigh]

I've tried to like Haskell, but when simple tasks start to look like complicated puzzles with many possible solutions, I get really put off. I want to get stuff done, not feel clever for managing to contort my algorithm into a different form whose runtime performance I'm uncertain of, all done merely in the name of avoiding a for loop.

[tome]

It's a shame you feel that way. Modifying an element of an array in Haskell is easy and the blog post gives almost exactly correct code, but for some reason places it under the title "we run into trouble when we realize there’s no built-in mutating assignment". But we don't run into trouble! Mutable arrays are provided in Haskell! Haskell has mutation! Here's the code

    import Data.Array.MArray
    import Data.Array.IO
    
    size = 10
    
    (!) = readArray
    
    main :: IO ()
    main = do
      -- 1. Declare the array
      arr <- newArray ((1,1), (size,size)) undefined
      let _ = arr :: IOArray (Int,Int) Integer
    
      -- 2. Initialize the array to 0
      sequence_ $ do
        i <- [1..size]
        j <- [1..size]
        return $ writeArray arr (i, j) 0
    
      -- 3. Set the diagonal to 1
      sequence_ $ do
        i <- [1..size]
        return $ writeArray arr (i, i) 1
    
      -- 4. Print the array
      sequence_ $ do
        i <- [1..size]
        j <- [1..size]
        return $ do
          arr_i_j <- arr ! (i,j)
    
          putChar $ if arr_i_j == 0
                    then '0'
                    else '1'
          if j == size
            then putChar '\n'
            else return () 

    > main
    1000000000
    0100000000
    0010000000
    0001000000
    0000100000
    0000010000
    0000001000
    0000000100
    0000000010
    0000000001

I've no idea why the blog post is written in such long winded style. Mutation in Haskell is not difficult!

[Ixiaus]

It depends on the task, of course, but I generally think Haskell is a very productive language for getting simple things done. Let me explain why.

There is indeed a side of the language and culture focused on elegance and there's also a side focused on pragmatism. Elegance and pragmatism aren't mutually exclusive but generally we use it as a type-safe getting things done language.

Imho its strength is in the type system even if that means starting your project out entirely in the IO monad with heavy let binding style, you'll still benefit from the type system. You can then, over time, decouple things, test things, etc.

I hope you don't give up on it because in the realm of pragmatic, unexciting, just trying to do my job software, Haskell really shines. It's just hard to see sometimes because not many production users are talking about that kind of use, you're usually seeing the library author's view which is going to be very different.

[Edit] I also think Rust is very promising for occasions in which you need the low level performance. If I can though, I will use haskell because its type system does such an amazing job at protecting myself from me and six months ago me.

[agentultra]

> when simple tasks start to look like complicated puzzles with many possible solutions, I get really put off.

Doesn't every language do this? Often I spend more time trying to decipher a C program than I do actually writing C code. With all of the variables, pointers, and mutation happening it can feel like a complicated puzzle and I get really put off.

What often happens is that the Haskell you read about online is far more theoretical than what you actually need to get practical work done using the language. It's often called that "Haskell Pyramid" or some such.

The only way I know of to "learn to like Haskell," is to not try but simply do it. Start from the beginning. Think of yourself like an empty jar. Put your mind back into the place where you first started programming and go from there. It will be frustrating at first re-learning many concepts you feel that you know but it's the best way IMO.

I had to do this in martial arts once... unlearn all the ways my body was used to moving and simply accept that I was going to start over and learn a completely new way. From the beginning. No excuses. No short-cuts.

> whose runtime performance I'm uncertain of

Reasoning about the run-time performance of Haskell programs is much more tricky, in my experience, than a strictly-evaluated language.

At least at first.

Like most things in Haskell once you are comfortable with the fundamentals you learn how the run-time works and ways to write strictly-evaluated code when performance is a concern.

[lmm]

I think you have to embrace it to appreciate it; Haskell's advantages wouldn't be there without its disadvantages. (Indeed I suspect I'd never have been able to appreciate Haskell if I hadn't learned Scala first, because Scala gave me a path from traditional imperative/OO code to Haskell-like code that doesn't exist in Haskell itself - but now I find myself wishing for a Scala without those things that I at one point needed). Stop worrying about the runtime performance, stop trying to write [previous programming language] in Haskell. Write expressions for the values that you want, then see if the performance is good enough for your use cases (and if not, have a quick go at profiling for common pitfalls rather than immediately jumping to writing it the imperative way); you might be pleasantly surprised (or you might find Haskell is genuinely unsuitable for your use case, though that's pretty rare IME).

[enord]

If you want to shovel bytes around in memory (or more likely, the memory model provided by your OS) that's your perogative, but there's nothing necessarily clever or contorted about relegating the responsibility of memory-management to your dependencies (including the compiler). Avoiding for loops is mainstream today, with your stream APIs, map/reduce, LINQ and what have you.

Loops are (in the general case) hard to reason about and provide few run-time guarantees. Predicate transformers with recurrence-relations are mostly intractable and a giant PITA. Variable assignment (or register overwrites) are hard to reason about, and loops (well... single entry/exit in lieu of goto, but whatever) were introduced to make it easier on the minds eye to follow the evaluation of programs and still they fail regularily.

Looping is not a simple task, it has real externalities wrt. program correctness (however you define it) and programming languages are providing more and more tools to avoid them and provide more run-time guarantees.

[MichaelBurge]

Thanks for reading!

The idea behind this article is that somebody who asks the question is probably confused about a lot of the core concepts in Haskell. So I write the same code in 20 different ways so that they can use their understanding of earlier concepts to understand later ones. Which hopefully makes them less confused.

That's a different goal than selling people on Haskell, or giving them the best solution and moving on. There is definitely a learning curve before you can hack out code without thinking too much about it.

[SirensOfTitan]

I ride a horse. I've tried driving a car, but it seems like a complicated puzzle with many buttons compared to a horse.

You have trained your brain to think about programming in a certain way. Haskell does things largely differently built on a set of completely different fundamentals and abstractions. For most of my non-CS friends taking a CS class in college: using a loop or basic recursion was a daunting task for them.

New ideas and abstractions require concentrated effort. I find it easy to forget the harder concepts I needed to grasp as I was learning programming (back when I was 11-12), but it's quite an important thing to remember while trying to understand something as different as Haskell.

[norea-armozel]

I always suggest people to learn Common Lisp or OCaml since they're easier to get into (OCaml is the easiest imo) if you want to get your head around the basic ideas of functional programming.

[beaconstudios]

isn't the whole point that you write code completely differently in functional languages? rather than writing loop code to populate an array, you'd do something like the following (in JS as I'm not a haskell programmer):

    const row = (len, onPositions) => {
        return (new Array(len)).map((item, index) => onPositions.includes(index) ? 1 : 0);
    };
    
    const matrixWithDiagonal = (len) => {
        return (new Array(len)).map((r, index) => row(len, [index]));
    }

the point being, that the code generates the result directly, rather than making space for values and then looping through toggling the positions that should be set to on.

note: you wouldn't really use the (new Array()) construct generally speaking (and it doesn't work with .map anyway) but it's easier than including underscore or ramda in the example.

[hood_syntax]

> completely differently

Not completely. Mutating state and I/O are done in a more imperative style via monads.

> the whole point

Depends on who you are I guess. The big wins for me in Haskell are the type system and purity by default. Of course I absolutely love the composability that functional programming offers, but there are other functional programming languages. Haskell I like for those reasons in particular. Disclaimer: I'm still a newbie when it comes to fp and Haskell.

[jordigh]

The original example is just to try to find something where you need to modify an array. Sure, you can create identity matrices without modifying an array, but that's just changing the parameters of the problem. If you really do need to change an array, how do you do it in Haskell?

Your solution is the typical thing you do in Haskell. You might know how to perform an algorithm by modifying an array, but now you suddenly have your hands tied and you can't do that anymore. Now you have to come up with an alternative way.

It's like someone really wants to implement bubblesort in Haskell but instead the solution ends up being to implement quicksort because the bubbling is difficult or unusual in Haskell.

[tome]

> isn't the whole point that you write code completely differently in functional languages?

That's certainly the conventional wisdom, but I think it's becoming less and less the case and we discover what are good styles to program in and imperative and functional styles are ending up converging somewhat.

[nihils]

If you want immutable data structures that simulate the behavior of mutable data structures look into Zippers. In this case, a list zipper.

[nihils]

For example, this problem of modifying the diagonal of a matrix can be solved quite easily:

  type Zipper a = ([a],[a])
  
  cursorOnDiagonal :: [[Int]] -> [Zipper Int]
  cursorOnDiagonal matrix = map (\(n,x) -> splitAt n x) (zip [0..(length matrix)-1] matrix) 

  flipToOneAtCursor :: [Zipper Int] -> [Zipper Int]
  flipToOneAtCursor = map (\(ys,x:xs) -> (ys,1:xs))   

  backToList :: [Zipper Int] -> [[Int]] 
  backToList = map (\(ys,xs) -> ys ++ xs)

If matrix == [[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0]], then:

  backToList . flipToOneAtCursor . cursorOnDiagonal $ matrix == [[1,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]]

[mrcwinn]

For those with access to another language, an alternate solution would be something like:

a = 1; a = 2;

Kidding. Really interesting write-up!