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 <Christophe.Troestler@umons.ac.be> 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.

--
Simon