Closed kim closed 5 years ago
There is one issue with this approach: it is no longer possible for the interpreter to extend the Peer
type without also changing the membership code (or tying a conversion function into the state-keeping mechanism). It seems preferable to impose a weaker constraint on the HyParView
monad:
class HasNodeId a where
type NodeId a
nodeId :: (Eq (NodeId n), Hashable (NodeId n)) => a -> NodeId a
class HasAddr a where
type Addr a
addr :: (Eq (Addr a), Hashable (Addr a)) => a -> Addr a
joinAny :: [(Maybe (NodeId n), Addr n)] -> HyParView n ()
joinAny = ...
@kim That seems reasonable -- typeclasses and type families to the rescue 😁
Aww, but it's more complicated than that: I still need to specialise to some Peer nodeid addr
, as otherwise we may unnecessarily hash a big structure for the HashSet
s/HashTable
s. So it'd be more the traditional "classy lenses".
That last idea turned out to be a very elaborate way of implementing id
, so I'm going with the "field lenses" approach. @adinapoli-mndc mind having another look?
Essentially, the membership protocol now knows that a peer is the tuple
(node id, network address)
, which the handshake protocol is obliged to return us (or an error if it doesn't support establishing a channel without a PSK, and none is provided).