I added a translation of this Kata over to Idris, adapting the structure of the code as close as possible (except moving (:<:) from a typeclass (interface in Idris) to a data type that covers all 3 instances similar to the Elem datatype in the Idris standard library.

Idris is a functional language like Haskell, but with a Dependent type system instead. It also, unlike Haskell, uses Strict instead of lazy evaluation.

https://www.codewars.com/kumite/63f93ea7cbfbb30047dcece3?sel=63f93ea7cbfbb30047dcece3

I'd appreciate any help or suggestions!

Description should be language-agnostic

maybe limit and suppress shouldn't be tested for negative values, or at least the fact that the input can be negative should be documented in the description. it's really not related to the task at hand at all and it's perfectly reasonable for implementors to assume that the input should be nonnegative as a precondition.

(marked as a spoiler because apparently the fact that limit and suppress can take negative counts is considered a spoiler :I)

src/ALaCarte.hs:1:104: warning:
    -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS
  |
1 | {-# LANGUAGE TypeOperators, DeriveFunctor, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, OverlappingInstances #-}
  |                                                                                                        ^^^^^^^^^^^^^^^^^^^^

In this kata we will walk through the first section of Data Type à la Carte.

It's not possible to access the paper using this link. If we're supposed to read it to solve this kata, then the link should be replaced with one that leads to the actual thing.

my solution keeps timing out on the real tests, and i'm not really sure where the bottleneck is in my code. help?

No sample tests in Haskell (at least).

• the name of the kata should be changed to "... Grouping"
• the function name must be changed to caesarGroup or alike

Without that, seeing sort everywhere is just too much wrong/misleading information.

Oof, that was a bit challenging at this stage of my Haskell understanding. I think they were supposed to be in approximate order of difficulty but I actually find Writer much easier than Reader. Perhaps they should be switched if that is usually the case? I don't have enough perspective on the matter to say, maybe it's just because I am very comfortable with monoids.

Also, I gather from @Voile's solution that the Writer type is flipped, perhaps that should be reassessed.

Monad definition of Coroutine is not tested thoroughly. Only the Done branch is tested, and both In and Out can be omitted and still pass the tests.

I am having trouble submitting my solution. It passes the default "Your Test Cases" test -- which is basically just a check that the code compiles.

However, when I try to submit, it times out at 6000ms. I don't know what to do at this point because submission testing is completely opaque.

This really sucks because I spent quite a bit of time learning this singleton stuff to get everything to work...

Can someone help me figure out why the tests are timing out?

The fact that it doesn't use (and doesn't even seem to allow!) closed type families is potentially teaching an obsolete pattern.

Mightn't it be a good idea to also implement ask :: Reader a a, set :: s -> Writer s (), put :: s -> State s (), and get :: State s s? I realise they may not be part of the core Monadic aspects of each, but are certainly important for their use.

Give ?? a proper name. Something like prettyAlgebra, evalPretty, prettify, render or similar, and remove any syntax errors. This enables one to use run test throughout the kata to check whether the types actually match. Otherwise, GHC's parser will give up on any occurence of ??.