api questions and some migration feedback about eio HOT 7 CLOSED

For Buf_read, the names were chosen to be compatible with Angstrom's names; e.g. https://github.com/inhabitedtype/angstrom/blob/5536d1da71469b49f37076beb5f75d34f448da5e/lib/angstrom.mli#L89.

I think Buf_write.printf would be a great addition (PRs welcome).

The use of Filename.concat in path.ml is a bug - it will use the wrong separator on Windows. There is a Path.split that might be useful for you. Calling it in a loop will get all the components. That might be a useful convenience function to add indeed (along with basename and dirname).

As an alternative to using a GADT, you can also cast to a concrete type: see https://github.com/ocaml-multicore/eio#casting

from eio.

Hi @talex5.

I did some initial exploration based on your answer here. If you think some bits are going the right direction (printf, components, basename and dirname) I can try and create some PRs out of it.

Re: casting.

As an alternative to using a GADT, you can also cast to a concrete type: see https://github.com/ocaml-multicore/eio#casting

Sorry I missed that section of the doc. This is spot on and I ended up preferring this style. Thanks! While writing the cast I wondered whether it would make sense to offer some canonical type alias in eio to simplify usage. I explored it a bit here, please let me know your thoughts.

Re: api compatibility. Thanks for pointing out the Angstrom constraint. It occurred to me that with what's already exposed by Buf_read and Buf_write, many things can be done in the user land depending on people's need, so I'm happy to do some exploration as third party libraries for now (example here). Thank you!

from eio.

Using primes for the generic types looks interesting. I didn't add them originally as there are so many types already.

I think basename etc should just be e.g. snd (split t). Why is extra logic needed?

from eio.

Re: basename

I expect the domain for basename and dirname to be any valid Eio.Path.t', thus my inclination was for their types to be:

  val basename : _ Eio.Path.t -> string
  val dirname : _ Eio.Path.t -> string

If you limit their implementation to the domain where split is defined, you'd end up with a string option in the returned type (thus the extra logic in the None case).

For the behavior, I based it on what I witness was the behavior of unix utils basename and dirname when typed in a terminal. For example:

$ dirname ''
.

You can have a look at the test cases I looked at here

I plan on creating separate PRs for the different things we talked about here, that way we'll be able to further discuss options there. Thank you!

from eio.

Re: basename in PR #648

from eio.

Re: type-aliases: I couldn't think of a technic that offers the same potential benefits without adding complexity and more types. I'll continue experimenting with it.

I believe my feedback is entirely covered at this point (thank you @SGrondin for #652 !), I'm happy to close this issue.

Thank you.

from eio.

(Buf_write.printf was added in #655)

from eio.