Parameters in queries for attributes that are unions

[slwu89]

When an AttrType is being modeled with some union type, queries with a parameter for something pointing to that attribute type won't work (errors). I am not sure if its possible to make them work given how the spans are set up in oapply, but I am documenting it here.

using Catlab, DataFrames

@present TestSch(FreeSchema) begin
    X::Ob
    A::AttrType
    a::Attr(X,A)
end

@acset_type TestData(TestSch)

data = @acset TestData{Union{Int,Symbol}} begin
    X=5
    a=[1,2,3,:four,:five]
end

testquery = @relation (x=xid, a=attr) begin
    X(_id=xid, a=attr)
end

query(data, testquery)
query(data, testquery, (attr=3, ))

[epatters]

Thanks for the report. If that code is failing, it's a bug.

[slwu89]

The error is as follows. I guess a possible fix would be to do something here https://github.com/AlgebraicJulia/Catlab.jl/blob/6c7c935f749775f017ba6220df655f1407280984/src/wiring_diagrams/Algebras.jl#L169-L179 to make sure the type sets are correct.

julia> query(data, testquery, (attr=3, ))
ERROR: Feet of spans are not equal: TypeSet(Int64) != TypeSet(Union{Int64, Symbol})
Stacktrace:
 [1] error(s::String)
   @ Base ./error.jl:35
 [2] oapply(composite::Catlab.Programs.RelationalPrograms.UntypedNamedRelationDiagram{…}, spans::Vector{…}; Ob::Type, Hom::Type, return_limit::Bool)
   @ Catlab.WiringDiagrams.WiringDiagramAlgebras ~/.julia/packages/Catlab/YRhzN/src/wiring_diagrams/Algebras.jl:54
 [3] query(X::TestData{…}, diagram::Catlab.Programs.RelationalPrograms.UntypedNamedRelationDiagram{…}, params::@NamedTuple{…}; table_type::Type)
   @ Catlab.WiringDiagrams.WiringDiagramAlgebras ~/.julia/packages/Catlab/YRhzN/src/wiring_diagrams/Algebras.jl:182
 [4] query(X::TestData{…}, diagram::Catlab.Programs.RelationalPrograms.UntypedNamedRelationDiagram{…}, params::@NamedTuple{…})
   @ Catlab.WiringDiagrams.WiringDiagramAlgebras ~/.julia/packages/Catlab/YRhzN/src/wiring_diagrams/Algebras.jl:158
 [5] top-level scope
   @ ~/Desktop/misc/tmp.jl:21
Some type information was truncated. Use `show(err)` to see complete types.

[slwu89]

@epatters I thought about this a bit, there's some tricky issues (or maybe I'm not seeing something obvious). The issue is setting up the constant function in SMultispan{1}(ConstantFunction(value, FinSet(1))). Obviously here the value given by the user will just be some atomic type and not a union, but the codom of the constant function will also be just that type. Hence the issue when comparing the feet of spans, because the type of the acset X passed at runtime will still be a union.

Even when calling the ConstantFunction constructor explicitly with the exact type of the attribute extracted from the acset at runtime with subpart_type, there will still be a problem because the type of the value will be one of the types in the union, but the constructor needs them to be exact, in the type signature ConstantFunction{T,Value<:T,Dom,Codom<:SetOb{T}}.

Any ideas? This may just be something to note and move on. Or insist that people use SumTypes.jl for these cases (kidding).