Instead, in the instance of PApplicative, you have to specify the rule of how to combine the "parameter" `t` and `u` into the final parameter `u`.
That way, I can create "parameterized" versions of Semigroup, Monoid, as well as Applicative, Alternative, Monad.
It also allows for create different flavours of "parameterized" kinds for ReaderT.
For example, I've created OverlappingWhichReader, DistinctWhichReader, and ManyReader newtype wrappers around ReaderT.
OverlappingWhichReader and DistinctWhichReader can combine reader that read `Which '[Int, Bool]` (polymorphic variant, analogous to 'Either Int Bool') with another reader that reader `Which '[Bool, String]` into a reader that can read `Which '[Int, Bool, String]`
ManyReader can combine reader that read `Many '[Int, Bool]` (heterogenous record, analogous to tuple (Int, Bool)) with another reader that reader `Many '[Bool, String]` into a reader that can read `Many '[Int, Bool, String]`
The single "parameter" still allows for the traditional changing state type for StateT.
For example, I've created ChangingState newtype wrappers around StateT, which changes the state parameter.
I've also created ManyState, which can combine StateT that modifies `Many '[Int, Bool]` with another StateT that modifes `Many '[Bool, String]` into a StateT that can modify `Many '[Int, Bool, String]`