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

[Gabriel Scherer <gabriel.scherer@gmail.com>]

On Fri, Aug 28, 2015 at 5:02 PM, Simon Cruanes
<simon.cruanes.2007@m4x.org> wrote:
> I tried to propose the structural type 'a sequence = ('a -> unit) -> unit
> as a glue between data structures [...] but so far Core and batteries
> do not use it.

This is a golden occasion to point out to everyone that contributions
adding `to_seq`, `of_seq` conversion functions to Batteries data
structures are warmly welcome. (If you are wondering what's a
practical step to help improving the "base library" ecosystem...)

You may find out that it is not in general trivial to implement these
(for the reason explained in this blog post:
http://gallium.inria.fr/blog/generators-iterators-control-and-continuations/),
but luckily all the hard lifting has already been done to support
functions to and from the Enum type, and generalizing these to also
provide sequence providers or consumers should not be too hard.

On Fri, Aug 28, 2015 at 5:02 PM, Simon Cruanes
<simon.cruanes.2007@m4x.org> wrote:
> 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