search

CQCL / brat

4 stars 0 forks source link

Smarter solving #35

Open croyzor opened 1 month ago

croyzor commented 1 month ago

In our journey to close #28 and #29, there are places where we could be doing better. For example, we fail on the following example:

mapVec(X :: *, Y :: *, { X -> Y }, n :: #, Vec(X, n)) -> Vec(Y, n)
mapVec(_, _, _, _, []) = []
mapVec(_, _, f, _, x ,- xs) = f(x) ,- mapVec(!, !, f, !, xs)

because we can't solve the number argument to the recursive call to mapVec. If we help the typechecker by matching on the number as succ(_) then we can work it out, but this shouldn't be necessary! We know that mapVec preserves vector size, so we should be able to work out from the use of cons that the argument needs to be n - 1

croyzor commented 1 month ago

Another good application of this would be with the fanout/fanin operators. They are checkable currently so the places they can be used is limited, but we could guess at the expected size using this framework, they'd be much more useful! e.g.

f(Vec(Qubit, 2)) -o Bit
f = ...

g(Qubit, Qubit) -o Bit
g = [\/]; f

h(Qubit, Qubit) -o Bit
h = [\/]; ..; f

g succeeds but h fails. I think we could do better!