Use DriveVoid typeclass instead of Default for underscored circuits

[t-wallet]

See https://github.com/clash-lang/clash-protocols/issues/92. Feel free to suggest different different names for the typeclass/functions.

[martijnbastiaan]

Void is a fairly widespread concept. Maybe DriveVoid or Sink? Though the latter clashes with the "idle sink" in clash-protocols.

[t-wallet]

Void is a fairly widespread concept. Maybe DriveVoid or Sink? Though the latter clashes with the "idle sink" in clash-protocols.

Sink is inaccurate, because we may have a Void source as well. I'll rename it to DriveVoid

[martijnbastiaan]

After thinking about this for a little bit: it seems to me that this abstraction isn't quite right. We'll end up with situations where multiple protocols use the same type (e.g., Signal dom Bool) with only one implementation possible. I therefore think the right type class is:

class DriveVoid a where
  driveVoidFwd :: Fwd a
  driveVoidBwd :: Bwd a

However, this means clash-protocols will have to change its definitions to circuit-notation, or circuit-notation will have to change its. AFAIK the differences are limited to:

type family Fwd a
type family Bwd a

-- vs

class Protocol a where
  type Fwd (a :: Type)
  type Bwd (a :: Type)

and

newtype Circuit a b = Circuit { runCircuit :: CircuitT a b }
type CircuitT a b = (Fwd a :-> Bwd b) -> (Bwd a :-> Fwd b)

-- vs

newtype Circuit a b = Circuit ((Fwd a, Bwd b) -> (Bwd a, Fwd b))

[lmbollen]

If we rewrite it to:

class DriveVoid a where
  driveVoidFwd :: Fwd a
  driveVoidBwd :: Bwd a

We might want to consider adding a possibility to stall the pipeline:

class DriveVoid a where
  driveVoidFwd :: Fwd a
  driveVoidBwd :: Bwd a
  driveVoidBwdNack :: Bwd a -- needs better name?

Then we could drop the IdleCircuit typeclass in clash-protocols