From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 6E88F7F168 for ; Fri, 28 Aug 2015 17:10:22 +0200 (CEST) IronPort-PHdr: 9a23:GdwayxFSa+bBW0lRFIparZ1GYnF86YWxBRYc798ds5kLTJ74pMuwAkXT6L1XgUPTWs2DsrQf27GQ7vGocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC1ILqhqibwN76XUZhvHKFe7R8LRG7/036l/I9ps9cEJs30QbDuXBSeu5blitCLFOXmAvgtI/rpMYwuwwZgf8q9tZBXKPmZOx4COUAVHV1e1wysebrrxjYUQyX5nZUbn8RnwFUBwXfpEXRXo3wqTf9rupwnhWAOsDtUbQ5Qxy/6qBtU1nhg2ENOmh910rej8g4qatapBOnqFRbwpXIKNWePf96O6fcZs8yRGxbX88XWTYXUa2maI5aNOsEOuAQhJPgrl0DtlPqHgipA+WpwSVVj3n7xutgi7x+OQSazEonBd1Y4yecl8n8KKpHCbP996LP1ziWKqoOgTo= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=Neutral smtp.pra=simon.cruanes.2007@m4x.org; spf=Pass smtp.mailfrom=SRS0=xOX8=JD=m4x.org=simon.cruanes.2007@bounces.m4x.org; spf=Pass smtp.helo=postmaster@mx1.polytechnique.org Received-SPF: Neutral (mail2-smtp-roc.national.inria.fr: domain of simon.cruanes.2007@m4x.org does not assert whether or not 129.104.30.34 is permitted sender) identity=pra; client-ip=129.104.30.34; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="SRS0=xOX8=JD=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="simon.cruanes.2007@m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of SRS0=xOX8=JD=m4x.org=simon.cruanes.2007@bounces.m4x.org designates 129.104.30.34 as permitted sender) identity=mailfrom; client-ip=129.104.30.34; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="SRS0=xOX8=JD=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="SRS0=xOX8=JD=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@mx1.polytechnique.org designates 129.104.30.34 as permitted sender) identity=helo; client-ip=129.104.30.34; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="SRS0=xOX8=JD=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="postmaster@mx1.polytechnique.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BcAgAWeeBVnCIeaIFeDoNhaYMjqhGQIoIshXuBPjwQAQEBAQEBAQEQAQEBAQEIFAlPgh2CBwEFIwQLATsbCyUdAgJFEgYBEhICiAUDEgQJr3ePNwOFJwsBAQEBHYh5gmmEImWCdC+BFAWFdAyPOAeFBol9hmiRbxGDVkBvgk0BAQE X-IPAS-Result: A0BcAgAWeeBVnCIeaIFeDoNhaYMjqhGQIoIshXuBPjwQAQEBAQEBAQEQAQEBAQEIFAlPgh2CBwEFIwQLATsbCyUdAgJFEgYBEhICiAUDEgQJr3ePNwOFJwsBAQEBHYh5gmmEImWCdC+BFAWFdAyPOAeFBol9hmiRbxGDVkBvgk0BAQE X-IronPort-AV: E=Sophos;i="5.17,425,1437429600"; d="scan'208,217";a="175212310" Received: from mx1.polytechnique.org ([129.104.30.34]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-GCM-SHA384; 28 Aug 2015 17:10:21 +0200 Received: from [10.146.90.135] (unknown [178.251.23.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id BFBD81408EFB4; Fri, 28 Aug 2015 17:10:18 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <20150828.140826.2157566405742612169.Christophe.Troestler@umons.ac.be> References: <20150828.140826.2157566405742612169.Christophe.Troestler@umons.ac.be> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----F4S5OTKZIP03EI1YPTGG7YUQ0ECECW" Content-Transfer-Encoding: 8bit From: Simon Cruanes Date: Fri, 28 Aug 2015 17:02:42 +0200 To: Christophe Troestler ,OCaml Mailing List Message-ID: <99BCDBE7-CB9C-416B-AFB6-EAA3E6F71BB1@m4x.org> X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Fri Aug 28 17:10:20 2015 +0200 (CEST)) X-Spam-Flag: No, tests=bogofilter, spamicity=0.027055, queueID=A5C601408EFC5 X-Org-Mail: simon.cruanes.2007@polytechnique.org Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really ------F4S5OTKZIP03EI1YPTGG7YUQ0ECECW Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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 ------F4S5OTKZIP03EI1YPTGG7YUQ0ECECW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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 ------F4S5OTKZIP03EI1YPTGG7YUQ0ECECW--