3 ms·

Oh, great, yet another library of data structures that introduce incompatible abstractions with both the standard library and the 3 other big libraries of data

by Drup 10y ago

Oh, great, yet another library of data structures that introduce incompatible abstractions with both the standard library and the 3 other big libraries of data structures[1,2,3], that is exactly what the OCaml ecosystem needs! :D More seriously, though, at least the naming convention is consistent. It looks a bit heavy on signature-indirection. I would really prefer if they used a standard iterator (gen[5] and sequence[6], for example, or the future one in the stdlib[7]) and settled for one serialization method (such as sexp) and get formatters everywhere. Also, please use ocamldoc or odoc[4] for your documentation. The one generated here is really terrible, even for OCam^W Reason standards. [1]: https://github.com/c-cube/ocaml-containers/ https://github.com/c-cube/ocaml-containers/ [2]: http://batteries.forge.ocamlcore.org/ http://batteries.forge.ocamlcore.org/ [3]: https://github.com/janestreet/base https://github.com/janestreet/base [4]: https://github.com/ocaml-doc/odoc/ https://github.com/ocaml-doc/odoc/ [5]: https://github.com/c-cube/gen/ https://github.com/c-cube/gen/ [6]: https://github.com/c-cube/sequence/ https://github.com/c-cube/sequence/ [7]: https://github.com/ocaml/ocaml/pull/1002 https://github.com/ocaml/ocaml/pull/1002

bordoley 10y ago
Hi Drup, The intent of Immutable-re is to provide a complete set of persistent immutable collections that complement the standard library and core. The initial release is limited to common Map, Set, and Vector types, but we have intent to add additional collections such as BiMaps, Multisets, and Multimaps. There is of course some overlap with the stdlib collections (SortedSet vs. OCaml Set, SortedMap vs. OCaml Map) but even in these cases, the Immutable-re implementations have slightly different characteristics from their stdlib counterparts, which provide added value. The public API is designed to be very Reason like, and familiar to web developers with experience in JavaScript, Java and C#, hence the naming conventions and camlCase. I've also considered adding an OCaml compatibility layer, which provides a more familiar API for OCaml developers. While the public API itself is heavily dependent upon signature indirection, these signatures are purely for documentation and not heavily depended upon within the implementation, which means the OCaml compat API may not include them at all. Regarding the choice of APIs for sequences, the current Sequence type is intentionally opaque and is internally designed to be compatible with the proposed standard OCaml Sequence (https://github.com/ocaml/ocaml/pull/1002 https://github.com/ocaml/ocaml/pull/1002). If/when, that PR lands, we will switch our internal implementation to be compatible with OCaml's while maintaining the same public API. Finally you are completely correct regarding documentation generation. Unfortunately refmt does not currently support outputting OCaml mli files including comments. This left me with the choice of hand rolling docs as I did or shipping ocamldocs lacking any comments explaining the types and functions. I chose the former. Thanks for your feedback.
- Drup 10y ago
  Well, multisets, multimaps and a lot of other things are also provided in containers and core. It's nice that you (already!) adopted that style of iterator. I'm not sure what an "OCaml compatibility layer" would mean. It's already OCaml-y: it's referentially transparent and full of functors and signatures! The main weird thing is that the type of compare is not the same (I understand why, but I find compatibility more valuable). The naming convention matters little, as long as it's clear, readable and consistent (OCamlers are not going to boycott a library because it uses camlCase). I don't think the signature indirection is a real problem, you just need a good tool for documentation generation that inlines signatures. You can ask the odoc people, I'm sure they would be happy to help you. I'm surprised there is no "reasondoc" tool just yet. :)
a-nikolaev 10y ago
Thank you for the link to c-cube/containers, didn't know about it, looks interesting! The above comment is relevant from the OCaml language ecosystem perspective. Although I think that possible segmentation is not a huge problem if it means wider adoption of the language. Especially considering that Reason maintains full compatibility with OCaml.

by Drup 10y ago

bordoley 10y ago

Hi Drup, The intent of Immutable-re is to provide a complete set of persistent immutable collections that complement the standard library and core. The initial release is limited to common Map, Set, and Vector types, but we have intent to add additional collections such as BiMaps, Multisets, and Multimaps. There is of course some overlap with the stdlib collections (SortedSet vs. OCaml Set, SortedMap vs. OCaml Map) but even in these cases, the Immutable-re implementations have slightly different characteristics from their stdlib counterparts, which provide added value. The public API is designed to be very Reason like, and familiar to web developers with experience in JavaScript, Java and C#, hence the naming conventions and camlCase. I've also considered adding an OCaml compatibility layer, which provides a more familiar API for OCaml developers. While the public API itself is heavily dependent upon signature indirection, these signatures are purely for documentation and not heavily depended upon within the implementation, which means the OCaml compat API may not include them at all. Regarding the choice of APIs for sequences, the current Sequence type is intentionally opaque and is internally designed to be compatible with the proposed standard OCaml Sequence (https://github.com/ocaml/ocaml/pull/1002 https://github.com/ocaml/ocaml/pull/1002). If/when, that PR lands, we will switch our internal implementation to be compatible with OCaml's while maintaining the same public API. Finally you are completely correct regarding documentation generation. Unfortunately refmt does not currently support outputting OCaml mli files including comments. This left me with the choice of hand rolling docs as I did or shipping ocamldocs lacking any comments explaining the types and functions. I chose the former. Thanks for your feedback.

Drup 10y ago
Well, multisets, multimaps and a lot of other things are also provided in containers and core. It's nice that you (already!) adopted that style of iterator. I'm not sure what an "OCaml compatibility layer" would mean. It's already OCaml-y: it's referentially transparent and full of functors and signatures! The main weird thing is that the type of compare is not the same (I understand why, but I find compatibility more valuable). The naming convention matters little, as long as it's clear, readable and consistent (OCamlers are not going to boycott a library because it uses camlCase). I don't think the signature indirection is a real problem, you just need a good tool for documentation generation that inlines signatures. You can ask the odoc people, I'm sure they would be happy to help you. I'm surprised there is no "reasondoc" tool just yet. :)

a-nikolaev 10y ago

Thank you for the link to c-cube/containers, didn't know about it, looks interesting! The above comment is relevant from the OCaml language ecosystem perspective. Although I think that possible segmentation is not a huge problem if it means wider adoption of the language. Especially considering that Reason maintains full compatibility with OCaml.