You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This code currently typechecks in Dialectic, even though the unit type () has no implementation of Transmit or Receive, making it such that enacting the session on this channel is impossible. It is only when we try to invoke the send or recv methods on the Chan that the error about Transmit or Receive would be thrown. Although in this case, it's clear that () is a silly channel type, we could imagine other scenarios with complex session types and/or channel backends with complex invariants about what can be sent (i.e. serialization constraints), which would make it non-trivial to tell at a glance whether a given session is possible to fulfill on a given backend.
Proposal:
pubtraitValidFor<Tx,Rx>:Session{}
We could then require this bound on Chan, so that all Chans are known to be statically valid for the whole session, and can't get stuck.
Issues/complications:
The calling-convention polymorphism means there is more than one way to send a value, and it's not possible to know even from the combination of the backend and the session type which calling convention will be used. Only one of them might be valid, or multiple, or none. How can we handle this?
We will need to correctly handle Split, where it must be disallowed to send/choose from the receive-only end, and recv/offer from the send-only end.
Lack of constraint kinds means we can't prove that ValidFor<Tx, Rx> implies any particular other constraint. In particular, in contexts polymorphic over Tx and Rx, we'll have to always add ValidFor<Tx, Rx>... and then go on to list precisely the constraints that this entails on Tx and Rx, despite ValidFor implying them already.
The text was updated successfully, but these errors were encountered:
Consider the following:
This code currently typechecks in Dialectic, even though the unit type
()
has no implementation ofTransmit
orReceive
, making it such that enacting the session on this channel is impossible. It is only when we try to invoke thesend
orrecv
methods on theChan
that the error aboutTransmit
orReceive
would be thrown. Although in this case, it's clear that()
is a silly channel type, we could imagine other scenarios with complex session types and/or channel backends with complex invariants about what can be sent (i.e. serialization constraints), which would make it non-trivial to tell at a glance whether a given session is possible to fulfill on a given backend.Proposal:
We could then require this bound on
Chan
, so that allChan
s are known to be statically valid for the whole session, and can't get stuck.Issues/complications:
Split
, where it must be disallowed tosend
/choose
from the receive-only end, andrecv
/offer
from the send-only end.ValidFor<Tx, Rx>
implies any particular other constraint. In particular, in contexts polymorphic overTx
andRx
, we'll have to always addValidFor<Tx, Rx>
... and then go on to list precisely the constraints that this entails onTx
andRx
, despiteValidFor
implying them already.The text was updated successfully, but these errors were encountered: