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

Intersection types #1041

Open
waywardmonkeys opened this issue Feb 11, 2016 · 0 comments
Open

Intersection types #1041

waywardmonkeys opened this issue Feb 11, 2016 · 0 comments

Comments

@waywardmonkeys
Copy link
Member

I found a concrete use case today where I could use intersection types (type-intersection).

Assume that:

  • I have a class <file-descriptor> which wraps an integer file handle.
  • I have bindings for read, recv, recvmsg, etc. I want them to operate on a readable file descriptor.
  • I have bindings for write, send, sendmsg, etc. I want them to operate on a writable file descriptor.
  • Most file descriptors will be both readable and writable.
  • I model the readable and writable states as mixin classes: define class <readable-mixin> (<object>) and define class <writable-mixin> (<object>).
  • These can not inherit from <file-descriptor> as it would create an invalid inheritance hierarchy.
  • I don't want read / write and friends to only take the mixin class as an argument, because if I do that, then getting the raw file handle will be a generic dispatch.

It seems like being use an intersection type here would be useful:

define function recv (fd :: type-intersection(<file-descriptor>, <readable-mixin>), ...)
  ...
end;

It is valid to get file descriptors that you know are read-only, so it would be nice to be able to signify that at the type system level. But I also wanted to be able to specify readable / writable for a more complicated reason within the posix-sockets binding which then led to thinking about all of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant