Kata

The initial solution exports everything, so that isn't a problem, is it?

Good point. I made sure that each of these operations works with at least two different types (like Int and Float). That should be enough right?

To make my life easier when testing I also added the (.=) function to implement. With that we also can have a nice isEven program, which I added aswell.

Last change is to the export/import list. Now everything is exported/imported by default, so that I don't have to touch these anymore if I decide to change an export again.

(These changes invalidated your solution)

If you choose to import everything in user solution, it should also be qualified so things defined in user solution will not collide with things defined in the tests.

Ah yes you are right. I changed the imports to back to being explicit.

The module Skeleton was a mistake on my part. I replaced it with the correct module Imperative.

I removed the unexported functions from the initial solution, I didn't have a good reason to include them. I also added the missing type definition for def.

Lasty, probably the biggest change, I removed the TODO types. while/if/else are now fully typed. That means that the typeclass I used also appears in the initial solution.

The Imperative type is still hidden, because I think it's interesting to figure out how to implement it.

Does it look better now? I am a bit worried that the variable/value typeclass thing is a bit too much at once.

Oh and with the removal of the TODO types the initial solution now compiles, which I think is great.

Is the new type definition for Imperative correct? It used to be a newtype, now it's data.

I used data so that I can define the left-hand side of the type while leaving the right-hand side out. newtype won't let me do that, but for the solution either newtype or data is fine.

Thanks for the feedback!

I use the more complicated signature to make it possible to compare both variables and values using built-in functions like (<). With Bool we wouldn't be able to compare the mutable variables we create. For example:

prog = def do
  a <- var 1 -- a has type `Var st Int`
  while a (<) 3 do -- here we compare `Var st Int` with `Int`
    ...

Does this make sense? If so I would add a hint for that.

It looks like this kata tried a different approach in the past, where Vars were instances of Num, but ended up with a version that's similar to what I am using here.

It makes sense. Could if' and friends take a monadic boolean instead of a pure one? You'd have to lift the built-in comparator and the value into the monad, of course, but that can be done polymorphically, so painlessly.

Thing is, with the current design, a > 3 && a < 10 is never going to work, and a ( monadic or pure ) boolean would offer that flexibility. It's not the essence of the kata, but it would seem very nice to have. :]

You'd have to lift the built-in comparator and the value into the monad, of course, but that can be done polymorphically, so painlessly.

I can image this being done by redefining the operators (for example (<) = someLiftFunction P.(<)), which I would like to avoid. How can it be done more painlessly?

Maybe my approach is already more complicated than it needs to be. For example while someVar (< 0) is a bit simpler because it only accepts a Var on the left side.

The meat of the kata should be defining mutable variabes and the if/else control flow, while keeping some kind of clean python-like syntax.

Let me know if you feel like there is anything else in the kata that makes it more convoluted than necessary.

It would look something like while (liftM2 (<) a (pure 3)) or while ((<) <$> a <*> pure 3), which of course looks nothing like Python. If you want to avoid someLiftFunction (<), the necessary intelligence will have to be built in to while, which is not the most modular or flexible design, but looks most like Python.