I am getting "uncaught exception: IOException of type UserError\nuser error (Expected expression to not compile but it did compile)", but stderr shows deferred type errors on all the tests that should not typecheck, which means my code is correctly making them not compile.

I tried implementing merge sort but the typechecker seems to go into an infinite loop.
I implemented bubble sort and it works on the sample test cases but exceeds the time limit on the hidden test cases, even when limited to 2 iterations. I assume that's got to be the compilation time limit since I don't see how a comptime algorithm could cause long runtime...

republished a fix that evaluates the output of identitySort and added some random testcasese.

for some reason solutionShouldHide fails to parse the Solution so I couldn't use it to block certain modules. Instead I tried to add an evaluation at the end to hopefully disallow that kinds of solutions.

Well, the kata has no random tests, so...

The typical Unsafe modules needs to be banned, otherwise this happens

I truly LOVE the idea of this kata!

Looks like it's been added back now.

Sample tests puts assumption on how TimeLinesState should be defined. The initial code has signature

data TimeLinesState s a = TimeLinesState {}

but sample tests can only be run with

data TimeLinesState s a = TimeLinesState {runTimeLinesState :: ... }

, which this is not specified anywhere, and is basically a fake degree of freedom.

The initial code is a mess. Shouldn't instance Applicative be defined before instance Monad? And the type hints can (and should) go to the initial code instead of the description.

Is the number of channels hardcoded as 2? Or is "multiple" to be taken as "unlimited" ?

The example where the state type is the same as the output type is less than ideal to clarify this.

Needs actual specs instead of just an example. Again, autor, this is an invitation to read your mind.

Needs actual specs. Examples are nice, but they are an invitation to read author's mind. Please specify how branchTimeLines is supposed to behave.

get, put, modify, state and gets also need actual specification. You can assume the normal behaviour is known, but their behaviour with multiple timelines is not.

using reads was actually quite bad of an idea