I strongly support the view that interoperability is important. Defining common, compatible types is necessary for a peaceful cohabitation of multiple stdlibs (types for json, xml, result, unicode, iterators, etc.) Some types should be provided by OCaml (result and Uchar imho); some other we should agree on. I tried to propose the structural type 'a sequence = ('a -> unit) -> unit as a glue between data structures (efficient, easy to provide, plays well with flambda) but so far Core and batteries do not use it. About the licensing, we have a diverse set of licenses, afaict. Cheers, Le 28 août 2015 14:08:26 UTC+02:00, Christophe Troestler a écrit : >Hi, > >The topic of a richer standard library was discussed extensively in the >past (before the advent of opam). I believe Yaron's opinion is the one >generally agreed upon: the small core team should focus on the compiler >and it is up to the community to take care of libraries. > >In the last 10 years, the community has not agreed on what the >“improved” standard library should be, there always have been competing >proposals and I do not see that stopping in the near future. I believe >this is not a bad thing, after all some applications have special >requirements — such as being able to be compiled to javascript — and it >is hard for a single library to satisfy everybody without being >bloated. > >However, as this discussion shows, there are a few places where we >could do a better job. > >1. INTEROPERABILITY: While many, possibly overlapping, libraries may be >seen as sign of liveliness of the community, they become a problem if a >user has to write boiler plate code to use them together. Thus I would >propose that we sit down together and define a minimal set of modules >for interoperability purposes. Since these modules would in general >only define some types, I propose to reserve the names type_* for that, >possibly with a version number at the end — so newer versions can >coexist with older ones and provide functions for backward >compatibility. Examples of such modules are: > - type_time: define date, time, and calendar types; >- type_html: define a common representation for HTML documents (a >library can of course provide its own but should also have a function >to export to type_html); > - type_xml >- type_linear: a common, linear, exchange format between various >containers (e.g. a lazy list); > - etc. > >2. LICENSES: Every opam package comes with a license which should help >companies to choose which ones to use. For the problem Hongbo >mentioned, maybe one could develop a tool that does the following: >given a white-list of licenses that the company has agreed are OK (e.g. >ISC) and a list of opam packages, the tool would warn if any of the >(recursive) dependencies does not have a “good” license. > >3. APPLICATION DOMAINS: A newcomer has to use resources like >https://github.com/rizo/awesome-ocaml/blob/master/sotu.md to understand >what packages are interesting for which domain. These resources are >maintained by hand. We should agree on a list of tags for important >application domains and add them to the appropriate opam packages. An >up-to-date list (linked to each package, homepage,...) can then be >generated automatically — and posted, say, to opam.ocaml.org > >One could also provide meta-packages to install sets of libraries with >a certain tag — for example all of batteries packages (once split). > >My 0.02€, >C. > >-- >Caml-list mailing list. Subscription management and archives: >https://sympa.inria.fr/sympa/arc/caml-list >Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >Bug reports: http://caml.inria.fr/bin/caml-bugs -- Simon