What is the intended purpose of the So type? Transliterating into Agda:

data So : Bool → Set where oh : So true

So lifts a Boolean proposition up to a logical one. Oury and Swierstra's introductory paper The Power of Pi gives an example of a relational algebra indexed by the tables' columns. Taking the product of two tables requires that they have different columns, for which they use So :

Schema = List (String × U) -- U is the universe of SQL types -- false iff the schemas share any column names disjoint : Schema -> Schema -> Bool disjoint = ... data RA : Schema → Set where -- ... Product : ∀ {s s'} → {So (disjoint s s')} → RA s → RA s' → RA (append s s')

I'm used to constructing evidence terms for the things I want to prove about my programs. It seems more natural to construct a logical relation on Schema s to ensure disjointedness:

Disjoint : Rel Schema _ Disjoint s s' = All (λ x -> x ∉ cols s) (cols s') where cols = map proj₁

So seems to have serious disadvantages compared to a "proper" proof-term: pattern matching on oh doesn't give you any information with which you could make another term type-check (Does it?) - which would mean So values can't usefully participate in interactive proving. Contrast this with the computational usefulness of Disjoint , which is represented as a list of proofs that each column in s' doesn't appear in s .

I don't really believe that the specification So (disjoint s s') is simpler to write than Disjoint s s' - you have to define the Boolean disjoint function without help from the type-checker - and in any case Disjoint pays for itself when you want to manipulate the evidence contained therein.

I am also sceptical that So saves effort when you're constructing a Product . In order to give a value of So (disjoint s s') , you still have to do enough pattern matching on s and s' to satisfy the type checker that they are in fact disjoint. It seems like a waste to discard the evidence thus generated.