Compositionality is paramount and category theory guarantees compositionality, but the author's criteria for what entails a good configuration language are woefully naïve.<p>Configuration is not about describing data, it's about control. Control over a system made of impure, effectful parts.<p>Configuration is a matter or <i>programming</i> a mutable computer, i.e. a way to specify the composition of effects that you want.<p>The configuration language is agnostic over the systems it controls, therefore it must provide semantics that preserve morphism in any of its interpetations. The language must be rich enough to accomodate for this. It is not enough to have one semantics.<p>Moreover, it must be rich enough to describe its own models. Yes, the interpretation of it by arbitrary systems must be expressible in the language itself in order to be meaningful and to preserve consistency with regard of its interpretations. In practice, this is done through types.<p>Additionally, configuration is a <i>global</i> activity, it's applied to the whole system, with many people changing conflicting aspects of it. Just like with any large evolving program, abstraction and typing are required for software engineering reasons alone.<p>Coincidentally, CUE is also a monoid, but it is more than that, it is a complete Heyting algebra (or a complete Boolean algebra in the case of closed world assumption), these objects also form very rich categories.<p>Another way to look at CUE is to view it as a semantic domain for the denotation of arbitrary types of arbitrary languages. It's suitable for this because it's a coherence space (Girard). All CUE operations are closed, preserving the structure of the space.<p>One interesting aspect of author's effort is that even if he was so naïve, category theory led him to a path that is correct. What he did is <i>incomplete</i>, a monoid does not suffice for a configuration language, but a monoid is <i>required</i>. This is saying something.