allow multi-master with trivial Bwd direction e.g. Signal

[jonfowler]

This allows you to write circuits like:

testDupCircuit :: Circuit (Signal dom Bool) (Signal dom Bool, Signal dom Bool)
testDupCircuit = circuit $ \x -> (x, x)

When the Bwd direction of the port is a () or other unit type defined by TrivialBwd.

It does so by replacing all Bwd expressions with unitBwd from a TrivialBwd typeclass (Note: we might want to change this to be called UnitC or something). The above is desugared into something similar to:

testDupCircuit = \(x_Fwd :-> (_,_)) -> unitBwd :-> (x_Fwd, x_Fwd) 

We could imagine a more general version of this which allowed more complex circuits to be fanned out by using a typeclass:

class Fanout a where
  fanoutC :: Circuit a (Vec n a)

However I don't particularly like this as it would be inserting logic without any obvious indication.

[martijnbastiaan]

I think either TrivialFanout or UnitBwd would make sense. I'm wondering whether this feature should be symmetrical: if a protocol has a trivial type on its Fwd, would we do something similar?

However I don't particularly like this as it would be inserting logic without any obvious indication.

Fully agree.

As for the review (but @cchalmers opinion is leading of course :-)):

• I don't really like the abbreviation of Direc. There's no real harm in writing it out IMO.
• I think it's time we add some unit tests to this project. Maybe add a test that verifies data is getting propagated correctly + bwd contains ()? Though maybe this is mostly covered by types anyway..
• I'm wondering what kinds of errors we get if you try to duplicate a protocol that doesn't support it. Is it intelligible enough?

[jonfowler]

I think either TrivialFanout or UnitBwd would make sense. I'm wondering whether this feature should be symmetrical: if a protocol has a trivial type on its Fwd, would we do something similar?

I considered this but it seems kind of pointless as I'm not sure when you'd really use something where there is data but it only flows backwards.

It doesn't look like you actually require the TrivialBwd constraint so it would let you accidentally duplicate anything?

Well it replace the x_Bwd with unitBwd which requires the constraint. Obviously this makes for a worse error message if you duplicate something like dataflow as you will get an error message like No instance for (TrivialBwd (Signal domain DFS2M)) - but I can't really see a way to avoid this.

[cchalmers]

I think it's time we add some unit tests to this project

At the very least cabal test should type check the examples. I got myself confused by cabal test passing. (which is what led to my "doesn't look like you actually require the TrivialBwd" comment which I deleted)

I'm wondering what kinds of errors we get if you try to duplicate a protocol that doesn't support it. Is it intelligible enough?

It's not too bad:

example/Testing.hs:122:25: error:
    • No instance for (TrivialBwd (Signal dom DFS2M))
        arising from a use of ‘unitBwd’
    • In the expression: unitBwd
      In the first argument of ‘(:->)’, namely ‘(unitBwd, unitBwd)’
      In the expression:
        (unitBwd, unitBwd) :-> (y_Fwd, y_Fwd, x_Fwd, z_Fwd, z_Fwd)
    |
122 |     idC -< (y, y, x, z, z)
    |                         ^

It's kinda annoying because GHC only gives one error at a time so you have to know that No instance for TrivialBwd means you've got multiple even though it's only pointing to one of them.

[jonfowler]

Yeah I had originally put my examples in test before I realised there was a whole load in examples

I have imported "Example.hs" in the test so it now is required to type-check