[MLIR] `DenseIntOrFPElementsAttr` vs. `SparseElementsAttr`?

… or why isn’t there a SparseIntOrFPElementsAttr?

I am just curious about the asymmetry of ElementsAttr sub-types between sparse and dense types. Is there a reason an IntOrFP specialization (sub-class) is only introduced for Dense representation and not for sparse one? Or are these types just added on a need-by-need basis (i.e. there was no need for sparse ElementsAttr except for integers and floating-point types and therefore there is no for a special sub-type)?