Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validity checking for sessions #43

Open
plaidfinch opened this issue Feb 23, 2021 · 0 comments
Open

Validity checking for sessions #43

plaidfinch opened this issue Feb 23, 2021 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@plaidfinch
Copy link
Contributor

Consider the following:

type S = Send<bool, Recv<bool, Done>>;
let Chan<S, (), ()> = S::wrap((), ());

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:

pub trait ValidFor<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.
@plaidfinch plaidfinch added the enhancement New feature or request label Feb 23, 2021
@plaidfinch plaidfinch self-assigned this Feb 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant