AlgebraicJulia / GATlab.jl

GATlab: a computer algebra system based on generalized algebraic theories (GATs)
https://algebraicjulia.github.io/GATlab.jl/
MIT License
23 stars 2 forks source link

Designing nested contexts #73

Open olynch opened 1 year ago

olynch commented 1 year ago

Just like ACSets, making a context struct has two steps. The first step is declaring the context (analogous to declaring the schema). We might also have an analogous naming convention to schema declaration, such as CtxArena.

CtxWrappedHom = @context ThCategory [dom::Ob, codom::Ob, morphism::Hom(dom, codom)]

The second step is to declare a struct that is based on that context. There are two options here. The first is to declare a model-specific struct, in which case we pass in a model as part of the struct declaration process, get the types associated with type constructors from that, and then only use the type parameters of the model as type parameters for the struct.

This might look something like:

@context_struct_concrete FinSetC FinFunction(CtxWrappedHom)

# =>

struct FinFunction
  dom::Int
  codom::Int
  morphism::Vector{Int}
end

The second is to declare a model-generic struct, which has type parameters for each type constructor and then additionally a type parameter for the model.

@context_struct_abstract WrappedHom(CtxWrappedHom)

# =>

struct WrappedHom{Ob, Hom, M <: Model{ThCategory.T, Tuple{Ob, Hom}}}
  dom::Ob
  codom::Ob
  morphism::Hom
end

We should also have an AnonContext struct, which wraps a NamedTuple, and then also a DynamicContext struct which wraps a Vector{Any}.

jpfairbanks commented 1 year ago

I think that we are going to have a ton of different structs if we are using the concrete option. The benefit is going to be avoiding the error message problem we have with ACSets. This would be a good issue to surface with Jeff.