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 1973B7F168 for ; Thu, 27 Aug 2015 22:10:59 +0200 (CEST) IronPort-PHdr: 9a23:gNXnnRAqr3x8P5NYbin1UyQJP3N1i/DPJgcQr6AfoPdwSP7zpMbcNUDSrc9gkEXOFd2CrakU0KyI7+u5BTBIyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/njKbsp9aKP1kArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIZoGJ/3dKUgTLFeEC9ucyVsvJWq5lH/Sl6o7XIZVi0zmxtMAg7KpDX7RYu55iDzs+443CiBIeX3S6o1UHKs9fE4ZgXvjXI2MCIw9Sn9g9Z2i7MT9AOmuxV6yYfOZoaEHPV7d6LZO9gdQDwSDY5qSyVdD9bkPMM0BO0bMLMd9tGlqg== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=yotambarnoy@gmail.com; spf=Pass smtp.mailfrom=yotambarnoy@gmail.com; spf=None smtp.helo=postmaster@mail-yk0-f176.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.160.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.160.176 as permitted sender) identity=mailfrom; client-ip=209.85.160.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-yk0-f176.google.com) identity=helo; client-ip=209.85.160.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-yk0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DJAQA1bt9VlLCgVdFehFgGxXECgTEHPBABAQEBAQEBARABAQEBBwsLCR8wgh2CBgEBAQMBEhEdARsLEwMBCwYFCw0qAgIhAQERAQUBHAYTFA6HdgEDCgilEYEvPjGLQIFsgnmKIQoZJw1WhEcBCxoBBQ6KUIEDgk+BU3CCaYFDBZU9iwaBbZMmhW8SI4EXF4IeHIFwIjOCTQEBAQ X-IPAS-Result: A0DJAQA1bt9VlLCgVdFehFgGxXECgTEHPBABAQEBAQEBARABAQEBBwsLCR8wgh2CBgEBAQMBEhEdARsLEwMBCwYFCw0qAgIhAQERAQUBHAYTFA6HdgEDCgilEYEvPjGLQIFsgnmKIQoZJw1WhEcBCxoBBQ6KUIEDgk+BU3CCaYFDBZU9iwaBbZMmhW8SI4EXF4IeHIFwIjOCTQEBAQ X-IronPort-AV: E=Sophos;i="5.17,423,1437429600"; d="scan'208";a="175109240" Received: from mail-yk0-f176.google.com ([209.85.160.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 27 Aug 2015 22:10:58 +0200 Received: by ykdt205 with SMTP id t205so32820837ykd.1 for ; Thu, 27 Aug 2015 13:10:56 -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 :content-type; bh=6EL/fOoi9tVn8C8jx74qWvg5hp/iIOKCKGTGX1KBzlY=; b=gC4uCcLsSBEm6TysNBqZ0oAQcTOln/amAh+uhhC2BWyGQn/bgNicoRyU4vyBdMuPG+ jVOOfeYuaq8wLkapRIigFq94MnzK0U8Jzf9dwBWi1kaGApc1uMBCenWpmtQd1uL05xL5 8ZJNsNgz4C/YyiQP7ZkryOeohVJz7pku8gCjWOL+bNfOwGrtrEcaxxax1lx0SaBU+Ti1 zWRtIMDCxOUjO/sDNx7dMpPU1WTdhT3nAbnvfRw+IqEssgqTO9ZdIAnhmRKA+RSOfiW0 7XSjTkKoJmOs6VxRPKguOmQiNA58miVDCrY1HMfc4mTcJQUN4aLHPf94/EK+dyrbTV7V yevg== X-Received: by 10.170.65.67 with SMTP id h64mr5147362ykh.122.1440706256644; Thu, 27 Aug 2015 13:10:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.93.8 with HTTP; Thu, 27 Aug 2015 13:10:37 -0700 (PDT) In-Reply-To: References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> <55DEE7E5.1020104@inria.fr> From: Yotam Barnoy Date: Thu, 27 Aug 2015 16:10:37 -0400 Message-ID: To: Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a11c044a2a73584051e5090c4 Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really --001a11c044a2a73584051e5090c4 Content-Type: text/plain; charset=UTF-8 I'd like to mention the merits of not having a large standard library. Consider the evolution of OCaml. Many of the paradigms with which OCaml was born, such as using exceptions everywhere, have gone out of favor. Hopefully, sometime in the near future, we'll have Modular Implicits integrated into the language. Assuming this happens, it will almost certainly impact what would be expected to belong in a standard library. The official standard library already carries around with it vestigial organs, such as the Stream module. This will only get worse if we add to it. At the same time, I recognize a need for a library to represent a large collection of data types and the functions over said types. It cannot all be miniature libraries in opam IMO -- for basic programming, there should be a curated source of basic and even some extended functionality. What seems to me better than a built-in standard library, though, is a reference to the best currently available libraries in each area, including a 'standard' collection of utilities/data structures. Such a reference could include space for the community to debate the pros and cons of various libraries, and perhaps even a voting system to indicate to potential users what the community thinks about said libraries. This is something I currently have trouble with in opam, since I have no idea if a given library is a) ancient and unmaintained b) the best in its class c) rising in popularity d) written by a pro and solid, even if not used much. The closest I have to that in opam is number of downloads, but given how much the ecosystem now relies on opam, I think a more advanced display is needed. -Yotam On Thu, Aug 27, 2015 at 3:55 PM, Martin DeMello wrote: > On Thu, Aug 27, 2015 at 3:35 AM, Romain Bardou > wrote: >> >> I agree about smaller, independent packages. This is a very general API >> design principle: avoid coupling (the fact that using a module implies >> using another). This may be the main reason I avoid external libraries. For >> instance, Martin Jambon's Yojson depends on biniou, cppo and easy-format. I >> believe Martin is an awesome programmer but this particular point just >> baffles me as there is absolutely no need for *any* external dependency to >> solve such a simple problem (JSON parsing, pretty-printing and AST >> constructors). I understand that Martin wants to reuse its own code and be >> able to integrate Yojson easily with other libraries of his, and that is >> great. For him and users of his other libraries. Not for those who just >> want a JSON parser and have had to install all dependencies manually on >> Windows. >> > > Part of the promise of an ecosystem of small libraries is that you should > be able to use them for any code you write, including other libraries. This > is not the same thing as API coupling; as an end user of library C you > should be able to use it without caring about whether it is self-contained > in terms of code or whether it uses libraries A and B internally. The fact > that dependencies need to be installed manually on windows is a failure of > the ocaml windows ecosystem (which I'm definitely sympathetic towards; I > once had to manually copy a bunch of code from batteries into my own > project just to avoid depending on it); it is not a sign that libraries > need not to depend on each other. > > martin > --001a11c044a2a73584051e5090c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd like to mention the merits of not having a large s= tandard library. Consider the evolution of OCaml. Many of the paradigms wit= h which OCaml was born, such as using exceptions everywhere, have gone out = of favor. Hopefully, sometime in the near future, we'll have Modular Im= plicits integrated into the language. Assuming this happens, it will almost= certainly impact what would be expected to belong in a standard library. T= he official standard library already carries around with it vestigial organ= s, such as the Stream module. This will only get worse if we add to it.
At the same time, I recognize a need for a library to repre= sent a large collection of data types and the functions over said types. It= cannot all be miniature libraries in opam IMO -- for basic programming, th= ere should be a curated source of basic and even some extended functionalit= y.

What seems to me better than a built-in standar= d library, though, is a reference to the best currently available libraries= in each area, including a 'standard' collection of utilities/data = structures. Such a reference could include space for the community to debat= e the pros and cons of various libraries, and perhaps even a voting system = to indicate to potential users what the community thinks about said librari= es. This is something I currently have trouble with in opam, since I have n= o idea if a given library is a) ancient and unmaintained b) the best in its= class c) rising in popularity d) written by a pro and solid, even if not u= sed much. The closest I have to that in opam is number of downloads, but gi= ven how much the ecosystem now relies on opam, I think a more advanced disp= lay is needed.

-Yotam

On Thu, Aug 27, 2015 at 3:55 PM, M= artin DeMello <martindemello@gmail.com> wrote:
On Thu, Aug 27, 2015 at 3:35 AM, Ro= main Bardou <romain.bardou@inria.fr> wrote:
I agree about smaller, independent packages. This is a very general API des= ign principle: avoid coupling (the fact that using a module implies using a= nother). This may be the main reason I avoid external libraries. For instan= ce, Martin Jambon's Yojson depends on biniou, cppo and easy-format. I b= elieve Martin is an awesome programmer but this particular point just baffl= es me as there is absolutely no need for *any* external dependency to solve= such a simple problem (JSON parsing, pretty-printing and AST constructors)= . I understand that Martin wants to reuse its own code and be able to integ= rate Yojson easily with other libraries of his, and that is great. For him = and users of his other libraries. Not for those who just want a JSON parser= and have had to install all dependencies manually on Windows.

Part of the promise of an ecosystem of small= libraries is that you should be able to use them for any code you write, i= ncluding other libraries. This is not the same thing as API coupling; as an= end user of library C you should be able to use it without caring about wh= ether it is self-contained in terms of code or whether it uses libraries A = and B internally. The fact that dependencies need to be installed manually = on windows is a failure of the ocaml windows ecosystem (which I'm defin= itely sympathetic towards; I once had to manually copy a bunch of code from= batteries into my own project just to avoid depending on it); it is not a = sign that libraries need not to depend on each other.

martin

--001a11c044a2a73584051e5090c4--