Is there any place you can reference that unrolls this lazyness for us? I find it hard to tell that it's using laziness.

Cool, I love these things that lazines brings :) Thanks for explanation.

No it shouldn't this is because for an empty list minimum is never evaluated as delete will handle the case of an empty list without touching it's first argument.

Will this not break with empty list?
λ> minimum []
*** Exception: Prelude.minimum: empty list

I chose inject instead of value. Do you think it makes sense to prevent uses of all not already defined functions? Is it even possible with the hidden function?

I guess you're right. I'm going to change it.

That is the reason I did not include it, otherwise it would be very easy, don't you think?

It's fine if you want to forbid Control.Applicative. However, you should mention this at some point in the description. If a user wants to cheat, (s)he can simply search for Applicative and take the default implementations of <$, <*, *> and so on.

and some combinators of it, in the first place, without letting them know what they're doing.

Well, the hidden isn't about those, who don't know what they're doing, but those, who've already written parsers, right? That being said, you could check whether there are already katas on Functor, Applicative and Alterantive. If there aren't any, one could create additional small katas, which ultimately lead to katas like this, where one needs to implement the correct instance. But that's just over the top of my head.

How about the following names instead:

value = pure             -- after all, we're injecting a _value_
apply = (<@>) = (<*>)    -- after all, we _apply_ a function in a parser to a parsed value
--      ^^^^^
--  defined in several libaries, but not in base: http://hayoo.fh-wedel.de/?query=%28%3C%40%3E%29

-- I'm using a magic eight ball here, but I think it's likely that `<|>` will get into Prelude in 2019.
orP   = (<<>>) = (<|>)
--      ^^^^^^
--      more like monoid (<>)

Ha, almost forgot about that one. I was all for it, until now, haha. Guess I have to rename some things and forbid usage of the Applicative versions. What do you think?

Sorry to disappoint you, you're too qualified. My intention was to teach people how to implement Applicative, and some combinators of it, in the first place, without letting them know what they're doing. This way they invented it by themselves. That is the reason I did not include it, otherwise it would be very easy, don't you think?

Sorry that I'm flooding your kata's discourse page, but that's the last one (hopefully): the AMP will break your kata, as <*> will be ambigous in future versions of GHC:

2.2 Future Prelude names
"The name X clashes with a future Prelude name" - Prelude will export functions called <*>, join and pure, so if a module defines its own versions of them, there will be name clashes. There are multiple ways of getting rid of this type of warning (in a future-proof way).

NOTE: This might or might not be a general Codewars problem, as I haven't seen the test cases yet. That being said, your current Control.Applicative test throws an exception, even though Control.Applicative isn't used anymore.

IOException (user error (Could not parse file (line -1, column -1): Ambiguous infix expression))

I will update this comment as soon as I've rewritten my submission - again.

EDIT1: Apparently, this is unrelated to your kata. Instead, there seems to be some hickup in hidden. I'll try to reproduce the behaviour tomorrow with a smaller example.