This talk seems like exactly what you are looking for for:

Gabriel Gonzalez - “A bare-bones Twitter clone implemented with Haskell + Nix” @ ZuriHac 2020 https://www.youtube.com/live/Q3qjTVcU9cg

You can use trace for that which is part of the base library:

https://hackage.haskell.org/package/base-4.19.1.0/docs/Debug...

Unrelated, but many thanks for organizing Zurihac year after year.

If you wanted to log from fibonacci, you would pass a some logger instance down to this function. In Haskell, this could be a record or a typeclass instance. In other languages, it could be an object or a struct. There is no fundamental difference. All the layers above would still have to pass this through; explicitly or implicitly.

The difference is most language have global state. See rust for example. It's not common to inject a logger, a "world" object for IO or anything for which you need monads in Haskell at all.

You are arguing from a concrete technical standpoint: "But you need to do the same thing in other language if you want to mirror Haskell monads". Sure, you are right. That also completely glosses over the point I'm making. I simply feel like the way haskell does it is unergonomic, it would also be unergonomic to something equivalent in other languages.

I don't know what a good solution would be, maybe a constrained partial type signature? Let the compiler pick the smallest constraint from a larger space of available constraints that fits with the usage and simply let the type checker bubble it up until you actually care to specify it? GHC doesn't support this but it should be possible in theory.

The builder interface has important performance benefits over working with lists: similar to e.g. concatenating many small Strings vs using StringBuilder in Java.

The builder interface indeed does not need to be monadic, you can simply append things using <> and get the same benefits.

The monadic interface is purely a syntactic enhancement on top of that, to reduce the number of operators you need.

Yes, we considered it, but I'm not sure if and when that'll happen. However, we also added PWA features [1], so you should be able to add it to your homescreen and it should work fine offline that way. But we're not experts on this stuff, so definitely let me know if you run into issues with this.

[1]: https://developer.mozilla.org/en-US/docs/Web/Progressive_web...

Clicking and keyboard work on the computer, and tapping and swiping works on touch devices. I was hoping this would be clear enough since I don't want to take up people's time with tutorials. Maybe we can add a separate "help" button or add this to the about page?

Yes. It would have been useful for me. I had never come across the original (2D Euclidean) game before, so I had no idea what the game objective was, nor that I was supposed to push boxes to achieve it.

Thanks again for the feedback, we've added a little "help" page now.

Yes please

I'm not sure if this is the same issue but we've heard from tons of people that the "undo" button should be at the bottom in order to make it easier to reach using a phone one-handed. We've now made that change. If you're referring to something else, please elaborate :-)

I second this as a great resource! Your game HyperRogue was also a big inspiration for this game.

Of course!

Thanks, please add a vaporwave-like soundtrack, and I will gladly put it on another one, dedicated to audio experiments (it will bring you some nice traffic).

Not really, if you wanted to do a version using only immutable arrays:

  import Data.Array
  
  fw :: Int -> Array (Int, Int) Int -> Array (Int, Int) Int
  fw 0 graph0 = graph0
  fw k graph0 =
    let fw' = fw (k - 1) graph0 in array (bounds graph0)
    [ ((i, j), min (fw' ! (i, j)) ((fw' ! (i, k)) + (fw' ! (k, j))))
    | (i, j) <- range (bounds graph0)
    ]

The only difference with a mutable implementation is that you use a new array for every k, whereas in a mutable version you would reuse these.