-
Notifications
You must be signed in to change notification settings - Fork 72
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
Relax the return types of Eio.Process.pipe #750
Comments
Forgot to mention, that I do realize that it is possible to explicitly cast any source-like type to just a source with: let source = (source_like :> Eio.Flow.source_ty Eio.Flow.source) But, I still think there's value in allowing |
Make sense. We already made this change for e.g. (and the Git version of cohttp-eio also relaxes the type for |
Hello @patricoferris, I'm Isaac Arogbonlo, and I've been accepted into the Outreachy contribution phase. I would like to work on this issue under your guidance and would be grateful if I could be assigned to it. Thank you. |
Glad to have you @Arogbonlo -- let me know if you need any help. Feel free to open a PR whenever you are ready/need more input and ping me! |
Thank you @patricoferris |
Hey @Arogbonlo -- before I can assign, do you mind making sure you have the project setup (i.e. OCaml installed and Eio building on Windows). This helps with managing the issues if we know you are ready to work on them. Let me know when you are ready and I'll reassign the issue, I'll also update the meta-issue to detail this step. Apologies for the confusion. |
Oh yeah i have those already set up. So I'm ready to begin. |
@create2000 I think you should pick up another issue while we give @Arogbonlo time to send his screenshot. Here is the link to other good first issues |
@oyenuga17 -- yeah, i have picked another issue. Thank you. |
Hey @patricoferris ,This shows I have everything set up! |
@Arogbonlo this only shows that you've got Ocaml running your system please attach a screenshot of your terminal running the Eio "Hello World" example in utop. |
1 similar comment
@Arogbonlo this only shows that you've got Ocaml running your system please attach a screenshot of your terminal running the Eio "Hello World" example in utop. |
|
Thanks @Arogbonlo -- the first screenshot you sent looked more promising (it was a compatible OCaml version for Eio, which needs OCaml 5+). Can I just double-check that this is running natively on Windows? It looks a little like WSL but I might be mistaken :)) |
|
Perfect, the Eio program isn't running there, but you should just be an |
hey @patricoferris @oyenuga17
And I've made the necessary changes to the ./unix/process.ml file |
Hey @Arogbonlo I think you'll also need to change the type on the module interface like the error states. |
thank you so much @oyenuga17 . I'll effect that and give you feedback! |
Hey @oyenuga17 @patricoferris as we can see in the pictures where I relaxed the return type of pipe, however after running the
|
You might want to look at #744, which made the same change for sockets. In particular, take care of the difference between |
Hey @Arogbonlo Thanks for your work. Firstly, do configure your editor to help working with OCaml. Next, I think it is important to understand what these type errors are saying. To start with, I would read about polymorphic variants in OCaml. In fact, @talex5 has an excellent blog post for just this: https://roscidus.com/blog/blog/2013/12/20/polymorphism-for-beginners/#polymorphic-variants. Further, here is small test program like the cohttp-eio example but without any dependencies that should type check after your changes: let read_constrained (src : Eio.Flow.source_ty Eio.Resource.t) =
Eio.Flow.read_all src
let () =
Eio_posix.run @@ fun env ->
let proc = Eio.Stdenv.process_mgr env in
Eio.Switch.run @@ fun sw ->
let src, sink = Eio.Process.pipe ~sw proc in
Eio.Flow.copy_string "hello" sink;
Eio.Flow.close sink;
read_constrained src |> print_endline |
Thank you for this. I'll look into this immediately. |
Wow! Having configured my editor to help working with ocaml, its all becoming very interesting and clear. Thanks so much for this @patricoferris Also, I'll have a good read on the article. I'm sure it would be of great help. Then, once I'm done, I could use the type case to test. |
Hey @patricoferris @oyenuga17 Thank you |
Motivation
Currently the
Eio.Process.pipe
function has the following type:This means that the created sources and sinks are required to be "closable". This restriction currently prevents compatibility with types that are monomorphically just sinks or just sources (i.e., without the
`Close
tag).My suggestion is to change the type of
pipe
to:This would allow the resulting sources and sinks to be implicitly used as any of the allowed subtypes.
Examples
To elaborate on why I think this is useful, consider the two examples below.
This works: flexible source consumers
If we expand the
read_all
type, it accepts[> `R]
flows, which of course type-checks because any additional variants, like`Close
are allowed. Thus, we can see thatread_all
is a "good" consumer and does not limit our types.This does not work: fixed flow types
Some APIs use monomorphic versions of source and sink types. For example, the Cohttp_eio.Body.t type is defined as:
Which means that the following example does not work:
Failing with:
This is fairly obvious, but unless, I missed something, there's currently no way to "restrict" a
[> source_ty] Std.r
to justsource_ty Std.r
in the Eio's API.We could argue that
Cohttp_eio.Body.t
, and/or functions that work on this type, should be more permissive and use open types, but, not only I think this is a non-obvious requirement for library authors, it also complicates the public APIs by exposing all the row variables.Conclusion
By changing the type of
Process.pipe
to use polymorphic types for source and sinks, we allow them to be compatible with their monomorphic versions.The text was updated successfully, but these errors were encountered: