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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 6A6487F168 for ; Fri, 28 Aug 2015 17:28:35 +0200 (CEST) IronPort-PHdr: 9a23:JQv12BT17tbiGWo9Hekq/50SS9psv+yvbD5Q0YIujvd0So/mwa64bBGN2/xhgRfzUJnB7Loc0qyN4/umBD1IyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/njKbvqtX6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPHs4CLCSAyJrlAGT2wQnwEAVxPE6Rb8GJzrryL8u/E7gnHCYuXzEaByXi6tufRFUhjt3QgOPSQ4/WWfscdwgbhWulr1qBV12Y/ZZMeOP/pzZK7HVdwfTGtFGM1WUnoSUcuHc4ITAr9Zbq5jpI7nqg5L9EPmCA== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-io0-f169.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.169; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.169 as permitted sender) identity=mailfrom; client-ip=209.85.223.169; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-io0-f169.google.com) identity=helo; client-ip=209.85.223.169; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-io0-f169.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AmAgDVfeBVm6nfVdFegzo1aQaDHa5gLY1VgjGDPgoCgTUHPBABAQEBAQEBARABAQEBAQYLCwkhLoIdggcBAQQSEQQZARsdAQMMBgULDQICJgICIgERAQUBHAYTCAwOh3YBAxINoh6BLz4xi0CBbIJ5iggKGScNVoRHAQEBAQEBBAEBAQEBARYBBQ6BFIVLhHWEIjYzB4JpgUMFlT+FBodtghCXCxIjgRcXhBA8MwGCTAEBAQ X-IPAS-Result: A0AmAgDVfeBVm6nfVdFegzo1aQaDHa5gLY1VgjGDPgoCgTUHPBABAQEBAQEBARABAQEBAQYLCwkhLoIdggcBAQQSEQQZARsdAQMMBgULDQICJgICIgERAQUBHAYTCAwOh3YBAxINoh6BLz4xi0CBbIJ5iggKGScNVoRHAQEBAQEBBAEBAQEBARYBBQ6BFIVLhHWEIjYzB4JpgUMFlT+FBodtghCXCxIjgRcXhBA8MwGCTAEBAQ X-IronPort-AV: E=Sophos;i="5.17,425,1437429600"; d="scan'208";a="144087161" Received: from mail-io0-f169.google.com ([209.85.223.169]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 28 Aug 2015 17:28:24 +0200 Received: by iods203 with SMTP id s203so96792854iod.0 for ; Fri, 28 Aug 2015 08:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=9AZCA5eMwISsAlOpnUCEUR4x+WOrv9lyq02nvSPQ3UE=; b=FigchDOoNbBHQv8VSDb+WmjgJkxwvgMMcL+I1+IcBVPPFC5Jmpn2DMTwMExPpToZ43 y/WvMpXNcJ/J3Mo2XB4vS2M0M/xD3L0SCljH2HC7ux3ludRzUeEPxhXdsq9XgyDfp17H nM/9zHq212EG18fQp3Hzj8DypCGV7JGU2ki42JGIo+Doo+szU+r5voT9Jnr2PbAZiCzh BrAOXcfVkvdUtk2on7DIpKPS+1VtXjyVrtn/h653prmLR1b4t0l3fIDgV/EA9oFoDcuu PmbjRgFQIZflylLDX6zxO3M69WIiDSwRSExXUPh+6jKMTWswTv7fnBfghxwqGGC0C4zK CMKg== X-Received: by 10.107.19.94 with SMTP id b91mr13776140ioj.144.1440775702718; Fri, 28 Aug 2015 08:28:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.68.132 with HTTP; Fri, 28 Aug 2015 08:27:43 -0700 (PDT) In-Reply-To: <99BCDBE7-CB9C-416B-AFB6-EAA3E6F71BB1@m4x.org> References: <20150828.140826.2157566405742612169.Christophe.Troestler@umons.ac.be> <99BCDBE7-CB9C-416B-AFB6-EAA3E6F71BB1@m4x.org> From: Gabriel Scherer Date: Fri, 28 Aug 2015 17:27:43 +0200 Message-ID: To: Simon Cruanes Cc: Christophe Troestler , OCaml Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really On Fri, Aug 28, 2015 at 5:02 PM, Simon Cruanes wrote: > I tried to propose the structural type 'a sequence =3D ('a -> unit) -> un= it > 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 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 = =3D ('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=C3=BBt 2015 14:08:26 UTC+02:00, Christophe Troestler > a =C3=A9crit : >> >> 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 =E2=80=9C= improved=E2=80=9D >> standard library should be, there always have been competing proposals a= nd 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 =E2=80=94 s= uch as being >> able to be compiled to javascript =E2=80=94 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 modu= les >> for interoperability purposes. Since these modules would in general only >> define some types, I propose to reserve the names type_* for that, possi= bly >> with a version number at the end =E2=80=94 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 =E2=80=9Cgood=E2=80=9D 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 maintain= ed >> 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 li= st >> (linked to each package, homepage,...) can then be generated automatical= ly =E2=80=94 >> and posted, say, to opam.ocaml.org >> >> One could also provide meta-packages to install sets of libraries with >> a certain tag =E2=80=94 for example all of batteries packages (once >> split). >> >> My 0.02=E2=82=AC, >> C. > > > -- > Simon