Hello all, like some other people, I do believe that using the internal logic of categories for describing objects, arrows and subobjects in a variety of contexts is a very good candidate for formalization.
The reason for this is that statements proven this level of generality, gives us statements about models in all categories. For example, anything we prove in the theory of groups will be true in for group objects in other categories (Lie groups, etc.). As a first step, I'm seeing that there is the potential for developing an efficient notation for arrows in cartesian/symmetric monoidal/monoidal categories, making their use more convenient.
At the moment, I have the following problem. I am starting with formalizing terms. I've come to the conclusion that the right setting to interpret them are multicategories. These are like categories, but instead of an arrow having a source and a target, an arrow is allowed to have multiple sources. For objects S1,⋯,Sn,T, we denote these arrows by Mul(S1,⋯,Sn;T). The classical example are vector spaces equipped with multilinear maps. In this case, these multicategorical arrows arise from the tensor product (or from a different viewpoint, the tensor product monoidal structure arises from this multicategory).
Multicategorical arrows get composed by taking an arrow f∈Mul(S1,⋯,Sn;T) and arrows gi∈Mul(R1,⋯,Rmi,Si) and putting them together to an arrow Mul(R1,⋯,Rmk,T). There is also an identity and we have corresponding identity and associativity rules. This models precisely the way that we combine terms in sorted logic. Multicategories also naturally provide a context for interpreting terms, at least terms where each free variable gets used exactly once and we're not able to permute the inputs. If we want to be able to permute the inputs, we need to use symmetric multicategories and if we want to use variables more than once, cartesian multicategories.
In the end, I want to be able to have a notation like term x y z w => f (x, g (y, z), w) for multicategorical arrows f and g be compiled into a multicategorical arrow with four inputs (in particular this then will also work for monoidal categories). I'm thinking of using this as a shallow embedding (i.e. no big Expr types, just notation) to keep this layer "lean" and giving us ways to delaborte arrows in this way and giving us better tactic mode behaviour.
However, with this idea I've quickly run into an important problem. A fully dependent version of multicategorical arrows is horrible, as you can see below. Stating the identity axiom requires transport with Eq.mp, and to me it looks like a pretty complicated type of transport (along two variables that depend on each other).
Header
importMathlib-- A base type of objectsvariable(X:Type*)structureMultiquiverwhere/-- `Mul ![x₁,..,xₙ] y` denotes the function symbols with input sorts x₁,..xₙ and the output sort y. -/Mul:{n:ℕ}→(Finn→X)→X→Type*-- Some auxilliary theorems/definitions for defining multicategories.privatetheoremflattenPf{n:ℕ}{m:Fin(n+1)→ℕ}(i:Fin(∑i,mi))(p:¬i<∑i:Finn,mi.castSucc):i-∑i:Finn,mi.castSucc<m(Fin.lastn):=byhaveh_lt:i.val<∑i,mi:=i.2rw[not_lt]atprwa[tsub_lt_iff_leftp,<-Fin.sum_univ_castSucc]defflatten{X:Type*}{n:ℕ}{m:Finn→ℕ}(R:(i:Finn)→Fin(mi)→X):Fin(∑i,mi)→X:=funi↦matchnwith|0=>Fin.elim0i|n+1=>ifp?:i<∑i:Finn,mi.castSuccthenflatten(funj↦R(Fin.castSuccj))⟨i,p?⟩elseR(Fin.lastn)⟨i-∑i:Finn,mi.castSucc,flattenPfip?⟩-- Two lemmas for transport at identity compositionlemmaflatten_fin_1_idx{n:ℕ}:(∑(_:Finn),Nat.succ0)=n:=bysorrylemmaflatten_fin_1{n:ℕ}{S:Finn→X}:flatten(fun(i:Finn)↦![Si])=S∘(congrArgFinflatten_fin_1_idx).mp:=bysorrystructureMulticategoryextendsMultiquiverXwhereid:(R:X)→Mul![R]Rcomp:{n:ℕ}→{m:Finn→ℕ}→{R:X}→{S:Finn→X}→{T:(i:Finn)→Fin(mi)→X}→(Πi,Mul(Ti)(Si))→MulSR→Mul(flattenT)Rid_comp_1:{n:ℕ}→{R:X}→{S:Finn→X}→(f:MulSR)→f≍comp(R:=R)(S:=S)(T:=funi↦![Si])(funi↦id(Si))f-- This is a heterogeneous equality because the types of the two functions are different.-- Fixing this requires transporting the terms into the same type by a combination of the two lemmas above,-- which is excessively ocmplicated.-- id_comp_2, and comp_assoc for identity composition on the right and composition associativity are missing here
So what I'm wondering now is:
How can I change the definition to make this type-theoretically more pleasant? I've thought about indexing by Fintypes instead of Fin n and another idea where we modify composition so that we only compose one input at the time, but none of the two ideas seem to help. Perhaps approaching this through categories of operators helps, i.e. allowing multiple outputs too, in the same way higher operads are done.
Are there any thoughts on the feasibility of developing a term notation as above (or something something similar)? How would you go about it? I am really inexperienced with metaprogramming and macros.
Are there any thoughts on the feasibility of developing a term notation as above (or something something similar)? How would you go about it? I am really inexperienced with metaprogramming and macros.
I remember doing this for cartesian closed categories although now that I'm a bit more experienced with metaprogramming I could probably come up with a better implementation now.
I will have a look soon, I think that notation for arrows in CC categories is also something really useful (it also subsumes the cartesian category case).
Sorry for not taking the time earlier, but this is pretty cool :slight_smile: FYI, CategoryTheory.CartesianClosed.applyMapHom does not build on newer mathlib versions.