Eio 0.1 - effects-based direct-style IO for OCaml 5

[antron]

@avsm

A secondary aim (what with @talex5 and I both being long-time core MirageOS developers) is to investigate how to replace the need for functors in Mirage libraries, and indeed to form the basis for MirageOS 5.

A large proportion of the objections EIO is currently receiving is on this issue, not on the content of the rest of your message. As far as I can tell, just about everyone is happy about the rest. However, capability objects are a major source of concern. To keep the discussion productive and not sway towards only stating things that nobody disagrees with, I will pick out this quote and comment on it.

This is the fundamental issue with proposing EIO in its current form as a “standard” I/O library: it would amount to a “Mirage-ification” of how I/O is done throughout the OCaml ecosystem, i.e. forcing the very real syntactic and conceptual overhead of Mirage-style programming on all users even though the vast majority of users don’t need it. A potentially foundational I/O library should not “use” the “opportunity” presented by the release of multicore and effects to sneak in and impose an unnecessary and very visible burden, which is of sectional interest to Mirage, on the rest of OCaml users.

Mirage is truly the only explanation I can think of for capability objects in EIO, and the multiple references to Mirage in your and @talex5’s messages makes me think that this is the real explanation.

1. Oblique mention has been made of JavaScript in this thread. Speaking as someone who routinely releases projects that are portable between native code, js_of_ocaml, and ReScript, I want to emphasize that from all my experience, capability objects in an I/O library have nothing to do with porting to JavaScript.

2. Speaking also as someone who has led work on two major I/O library projects (Lwt and Luv), capability objects have nothing to do with ordinary native I/O, neither in terms of composability, nor security, nor any other property I have ever been aware of to date, at least in an OCaml setting.

3. I challenged all of the other arguments (known to me) in favor of capability objects in my earlier post — are you able to address them?

If not, I think we would have to come to the conclusion that the capability objects aspect of EIO is really related specifically to Mirage:

@avsm

the addition of a single argument to eio calls is sufficient to eliminate those functors while improving performance and retaining portability. We would like MirageOS code to be “just like normal code”, and this has been true since 2013 when the effects research started.

and is a service to Mirage at the expense of the rest of OCaml. It is essentially a way to make people pay the cost of being portable to Mirage (or almost) even though they don’t need that.

It might then be an example of a conflict that arises from the same group of people working on the future of OCaml in general, and also developing Mirage. If EIO is meant to be foundational, it is wrong to insert something so pervasive, visible, awkward, and annoying, but useful primarily only for Mirage.

Note that I have nothing against Mirage or its development, in fact I intend to use it myself.

@avsm

I find the argument that foundational libraries should be conservative and unopinionated to be somewhat uncompelling at this stage in OCaml’s life.

Neither I nor @lpw25 made an argument that EIO should be different because it should be conservative or unopinionated.

We made the argument that EIO should be different because of specific technical and design issues, which we began to detail. Only after that, we summarized that detailing as “conservative” or “unopinionated” on those aspects of EIO’s design which we object to.

More directly, even if EIO will be opinionated, it should not be opinionated specifically in favor of Mirage.

There is no question about EIO being conservative, opinionated, or experimenting on any of the other things. Your comment is therefore dismissive, because it deliberately blurs focus, from real technical objections on a specific issue, to generalities, rhetoric, and listing everything else about EIO.

There is another argument about what stage of life OCaml is in:

1. OCaml effects and multicore are probably the largest opportunity OCaml will ever get to attract a large general-purpose user base.
2. We should not waste this opportunity with awkward, overly experimental libraries that pursue sectional, strongly biased, or academic interests and will naturally turn away users.

Note that I am not saying that everything EIO is doing is biased, academic, or impractical. I am commenting on one, but very visible and pervasive aspect of its current API. It is the very first thing someone will notice when using EIO (and, I claim, will keep noticing and being justifiably annoyed by).