Parameters in queries for attributes that are unions

[slwu89]

Parameters in queries for attributes that are unions

[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

Catlab.jl/src/wiring_diagrams/Algebras.jl

Lines 169 to 179 in 6c7c935

	# Add an extra box and corresponding span for each parameter.
	if !isempty(params)
	diagram = copy(diagram)
	spans = vcat(spans, map_pairs(params) do (key, value)
	box = add_part!(diagram, :Box, name=:_const)
	junction = key isa Integer ? key : only(incident(diagram, key, :variable))
	add_part!(diagram, :Port, port_name=:_value,
	box=box, junction=junction)
	SMultispan{1}(ConstantFunction(value, FinSet(1)))
	end)
	end

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).