Re: [Caml-list] We need a rich standard library distributed with OCaml, really

[Simon Cruanes <simon.cruanes.2007@m4x.org>]

[-- Attachment #1: Type: text/plain, Size: 3762 bytes --]

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.
>
>-- 
>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

[-- Attachment #2: Type: text/html, Size: 4000 bytes --]