CoffeeScript random tests sometimes include two or three zero arguments. That's not a valid triangle, and according to the description shouldn't be tested.

One of the arguments equals zero.
You will not be expected to handle any erronous data in your solution.

i think var will make counter accessible via constructor, and there was no test for this case

I don't have a full understanding either, but some observations:

List ( and Boolean, etc. ) are newtypes, which have no runtime overhead, so everything is function application ( foldr is actually a no-op! ) which may be optimised by GHC in weird, unpredictable, unintuitive, but aggressive and very efficient, ways. I'm no longer a beginner in FP, Haskell and GHC, but I can't always predict performance characteristics either. Memoisation can be fickle; sometimes it works and sometimes it doesn´t.

"a single foldr per list argument" is not the be-all-and-end-all of runtime performance; it is mostly there to clarify that you can't use tail ( which is necessarily O(n) ) to simulate pattern matching because it will completely bugger performance, but there are more ways to bugger performance. Using a single foldr in append may postpone evaluation of the other argument long enough that it is ultimately faster than using two, which may not be lazied away long enough. Encapsulating a foldr in cons may help because of memoisation somehow - but I'm speculating here; this is where I lose understanding of performance as well.

Ultimately, if it works, it works. Which is somewhat unsatisfactory, because the test framework is not very good at showing where a timeout happens. And performance analysis in GHC Haskell is not straightforward, esp. for an FP beginner. My apologies. It will probably get better for you; you seem a smart and experienced programmer ( you were one of the first solvers I noticed and followed on here, 7 years ago ), and in time, you'll learn.

There seems to be something wrong with your sortBy as well - it is indeed timing out ( yay for the View Solution on comments :). It might be your append, which has two foldrs where one would suffice ( changing that makes sortBy not time out ). Have a look at the GHC source for (++). That does pattern mathing, but it might give you a hint at how to get away with using one foldr instead of two.

OT: I've written lots of compilers. Some kata ask for assembly compilers ( cq. interpreters ), and I've done those in both JS and Haskell; I've also written several LC compilers in both JS and Haskell. This kata only uses an embedded parser, not a complete compiler, to check LC syntax embedded in Haskell ( which is ported / reused in several embedded LC kata in JS, Python and Haskell ). Piece de resistance is the LC to JS compiler that's underlying LC as a CW language of course - but credit where credit is due: Carrot did the compiler part on that one; I only wrote the parser part. I did write a LC to JS compiler for the Compiler to Lambda Calculus kata, but that uses strict evaluation ( much easier :), as opposed to the lazy evaluation for the LC to JS language compiler.

Yeah, it does, thanks! I knew that my zipWith is garbage, but I thought I would fix the problems in order of their appearance - I have no idea right now how to interweave them folds anyway. The test timing out at sortBy together with the "single fold" hint threw me off the track. It would be nicer if the tests would only test the performance of what function they are about (or the ones that have already been tested up the list), but I don't know how complicated it would be to change them. A note in the "Performance" part would suffice too. Or even this discussion probably )

As an offtopic - have you written a whole new compiler just to make more katas here?

Sorting can't be done in O(n), so "single foldr per list argument" does not apply to sortBy. My own solution uses insertion sort. If you have performance problems, make sure drop and zipWith are O(n) and not O(n^2).

My apologies for the confusion. Should this be explicitly clarified in the description?

Will this really work? :D

:D Bravo!

!! is used to convert a truthy/falsy value to its boolean equivalent.

let num = 5; (truthy)
!num // false
!!num // true

let num = 0; (falsy)
!num // true
!!num // false

comparing 5 with !!5 would be the equivalent of comparing 5 with true (which is false)
5 === !!5
5 === true

The only reason people still use it over Boolean (other than wanting to look like elite hackers) is because it's something like 10-15% faster (last time I checked)

I feel dumb but I don't understand this solution...

thanks for the tip

OMG!!