我并不声称自己是这些主题的专家，但我也许可以对这个想法有所了解。
让我们首先考虑范畴论。范畴论是对数学结构的高水平研究。范畴的概念很笼统，许多数学对象构成范畴。范畴论最初被认为是极其纯粹和抽象的，但由于这些东西经常出现在数学中，结果证明它在计算机科学甚至量子力学等应用学科中有很多用途。Monads 被证明在推理函数程序的语义方面非常有用，这些语义通常用指称表示（因此不强制任何类型的计算顺序，只是结果）。由此也意识到monad也是一个非常好的设计模式用于编写函数式程序，它的实用性导致它在 Haskell 的设计中非常突出（即 do 表示法等）。Functors、Applicatives、Monoids，都在后来作为对象不如 monads 强大，但因此也更具应用性（不是双关语！）。
然而，范畴论以更一般的方式研究这类结构，事实证明这与数学（和物理等）的许多领域相关。作为非专家，目前尚不清楚这有多少与复杂性理论有关，但让我们试一试。
复杂性理论关注计算的可行性。图灵和其他人已经表明，有些函数通常是不可计算的（例如停机问题、忙碌的海狸问题等），但原则上特定计算有多容易的问题通常是一个更难的问题。您可能知道，算法（可以表示为图灵机）可以根据其渐近运行时间归类为复杂性类。已经确定了许多复杂性类别（请参阅The Complexity Zoo），但对这些类别的结构知之甚少。著名的P = NP问题显示了推理复杂性是多么困难。
从对复杂性类的性质以及证明它们之间关系的难度的直觉来看，我认为在复杂性类中建立类别会很棘手。显然图灵机的集合形成了一个范畴，但是 O(n) 中的机器集合呢？还是 P 中的机器集？对于复杂性专家来说，这可能是一个很好的研究方向，但也可能不是！就个人而言，我不能说没有更多的工作。
现在让我们考虑您在 Monoid 和并行化策略中的复杂性示例。如果第二部分看起来与第一部分关系不大，那是因为我认为这些是非常不同的概念。首先是类别和复杂性的数学，其次是某些设计模式中并行化算法的细节。
如果我们知道某个类型是 Monoid，我们可以推断使用它的复杂性是什么？这是来自的类定义Data.Monoid
class Monoid a where
mempty :: a
mappend :: a -> a -> a
mconcat :: [a] -> a
mconcat = foldr mappend mempty
当然，我们不能说复杂性，因为我们所知道的只是类型，正如您所猜测的那样。mconcat文档对Data.Monoid中的默认实现有这样的说法：
-- ^ Fold a list using the monoid.
-- For most types, the default definition for 'mconcat' will be
-- used, but the function is included in the class definition so
-- that an optimized version can be provided for specific types.
我要说明的一点是，这mconcat不一定能从其他操作的复杂性中概括出来。在许多情况下，很难证明不存在某些更快的算法。mconcat在这种情况下可以手动实现。
您还提到自动定义并行策略。Haskell 当然允许定义各种不同的策略，其中许多有用的策略已经在Control.Parallel.Strategies. 例如， parList 将策略并行应用于列表的每个元素：
parList :: Strategy a -> Strategy [a]
parList strat [] = ()
parList strat (x:xs) = strat x `par` (parList strat xs)
由此可以定义一个并行映射函数。
parMap :: Strategy b -> (a -> b) -> [a] -> [b]
parMap strat f xs = map f xs `using` parList strat
using :: a -> Strategy a -> a
using x s = s x `seq` x
请注意，这允许分离实现和并行化。我不认为这种概念可以很容易地自动化，尤其是仅从描述单个算法复杂性的注释中。
综上所述，范畴论有可能成为未来复杂性研究的有用工具。但是我不认为这可能会导致并行化策略的自动生成。