Great kata about GADT stuff :)

Because the testing code wrongly entangles with the paren type to be defined. I managed to reduce the entanglement by using an independent definition in the testing code.
This may fix this problem.

Thank you, should be fixed by now.

Thank you, should be fixed now.

The tests assume Paren is defined in a specific way. This works:

data Paren :: Nat -> Nat -> * where
    PEmpty :: Paren Z Z
    PLeft :: Paren a (S b) -> Paren (S a) b
    PRight :: Paren a b -> Paren a (S b)

but this does not:

data Paren :: Nat -> Nat -> * where
    PEmpty :: Paren Z Z
    PLeft :: Paren a (S b) -> Paren a b
    PRight :: Paren a b -> Paren (S a) (S b)

The latter will cause this error message:

test/Kata/TestSpec.hs:101:38: error:
    • Couldn't match type ‘'S 'Z’ with ‘'Z’
      Expected type: Paren s ('S a2)
        Actual type: Paren ('S 'Z) ('S 'Z)
    • In the expression: PRight PEmpty
      In the expression: [PRight PEmpty]
      In an equation for ‘appendRights’:
          appendRights PEmpty = [PRight PEmpty]
    |
101 |               appendRights PEmpty = [PRight PEmpty]
    |                                      ^^^^^^^^^^^^^

But there is nothing that says only the former should be correct (since both are isomorphic); and from the usage we only care about the Paren n Z cases.

Can you force
{-# OPTIONS_GHC -Wincomplete-patterns -Werror=incomplete-patterns #-}
?
It would ban solutions like this. In previous catas too.

This taught me that GHC is our friend, and to (at least kinda) think about the type unification process when reading error messages. I don't know if it'd help more people attempt this, but may some links or exposition about GADTs would help?

Thank you for the suggestion, it's inspiring.
It actually got me to ponder the design again and realized instance could not be imported before the data type is defined.
And test have been improved to prevent the situation from happening.

This is what Beta is for. Don't worry too much about invalidating solutions ( you have all of three! ) if the kata needs a redesign.

Sure, if you can do it without breaking existing solutions, you don't have to break them. But if it will improve the design ( and defining instances in Preloaded so users can't break them is better design ), don't go bending over backwards ( or into other unnatural poses ) to keep existing solutions valid.

If Eq has to be imported, people can just touch up their existing solution to have a valid solution under the new and improved tests if they value that. They don't have to do it for the points, they keep those anyway.

thank you for poniting out. you are right, But inorder to not invalidate already valid answers, I decide to update the test so this won't happen.

I think you should probably put the eq instance in a file other than the one the user has access to: wouldn't it be possible for me to just change it in order to pass the tests?

This function has been made into a next kata, try it out to see if there is any error
https://www.codewars.com/kata/5fff4fe1ffa782001ea74a3b/

Yeah, you can use infinite types if you wrap them in a newtype.