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 2A6D27F168 for ; Fri, 28 Aug 2015 01:25:16 +0200 (CEST) IronPort-PHdr: 9a23:wOIdmh+W+72frv9uRHKM819IXTAuvvDOBiVQ1KB80uscTK2v8tzYMVDF4r011RmSDd6dta8P0bSempujcFJDyK7JiGoFfp1IWk1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXsq3G/pQQfBg/4fVIsYL+lQciM0o/tiaibwN76XUZhvHKFe7R8LRG7/036l/I9ps9cEJs30QbDuXBSeu5blitCLFOXmAvgtI/rpMYwuwwZgf8q9tZBXKPmZOx4COUAVHV1e1wysfzsqRDGBSGG/H0bQy1Cgx1UCg3P5Qv8WYbZvS7zt+470y6fa4m+ars9XDDqyq5qTB7uh28jNiUluDXcg8l0yaZauw6JphplwoeSbpvDZ9RkeaaIUckHXSIVUtxMTz1GDcC3Zo4LJ/gGPeEepI748Qhd5SCiDBWhUbu8ggRDgWX7iOhji7ws Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=drupyog+caml@zoho.com; spf=Pass smtp.mailfrom=drupyog+caml@zoho.com; spf=None smtp.helo=postmaster@sender153-mail.zoho.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of drupyog+caml@zoho.com) identity=pra; client-ip=74.201.84.153; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="drupyog+caml@zoho.com"; x-sender="drupyog+caml@zoho.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of drupyog+caml@zoho.com designates 74.201.84.153 as permitted sender) identity=mailfrom; client-ip=74.201.84.153; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="drupyog+caml@zoho.com"; x-sender="drupyog+caml@zoho.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@sender153-mail.zoho.com) identity=helo; client-ip=74.201.84.153; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="drupyog+caml@zoho.com"; x-sender="postmaster@sender153-mail.zoho.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CXAQDYm99VlJlUyUpeg29pq2OUFoV/AoE+PBABAQEBAQEBARABAQEBBwsLCR8wgh2CBwEBBCMgASMRAw4LGAkWCAMCAgkDAgECAQ8lEQYBDAYCAQEQiAQBAwEEDQ2wQHGEawKKEyIoDRiFBQEBCAEBAQEBFgMEil6BA4JPgVNwgmmBQ5VCgUWDQYYAgW2DAYV2ii+HO4I1HIFWb4JNAQEB X-IPAS-Result: A0CXAQDYm99VlJlUyUpeg29pq2OUFoV/AoE+PBABAQEBAQEBARABAQEBBwsLCR8wgh2CBwEBBCMgASMRAw4LGAkWCAMCAgkDAgECAQ8lEQYBDAYCAQEQiAQBAwEEDQ2wQHGEawKKEyIoDRiFBQEBCAEBAQEBFgMEil6BA4JPgVNwgmmBQ5VCgUWDQYYAgW2DAYV2ii+HO4I1HIFWb4JNAQEB X-IronPort-AV: E=Sophos;i="5.17,423,1437429600"; d="scan'208,217";a="144012764" Received: from sender153-mail.zoho.com ([74.201.84.153]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 28 Aug 2015 01:25:14 +0200 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=v7duLm6TbhI0b9QWBUgvua7hExi0gD/BHLqbumchVy2cYhSkGz3SwNclumKIYHEFjYxOB8+sh1Uo BAKpV9ZrZ+abtDz/+V+D/W/l9JSHrpNUHce/dxFZ13y30vd0q6Cm Received: from [192.168.198.84] (global-1-100.nat.csx.cam.ac.uk [131.111.184.100]) by mx.zohomail.com with SMTPS id 1440717911011944.5925145600681; Thu, 27 Aug 2015 16:25:11 -0700 (PDT) To: Yotam Barnoy , Ocaml Mailing List References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> <55DEE7E5.1020104@inria.fr> From: Drup Message-ID: <55DF9C33.6040300@zoho.com> Date: Fri, 28 Aug 2015 01:24:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070201020709060909080203" Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really This is a multi-part message in MIME format. --------------070201020709060909080203 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit https://github.com/rizo/awesome-ocaml ? (my opinion is that awesome-ocaml is not curated enough and lists things that are not stable nor usable, but at least it's a good step) Le 27/08/2015 22:10, Yotam Barnoy a écrit : > 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 > > --------------070201020709060909080203 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
https://github.com/rizo/awesome-ocaml ?

(my opinion is that awesome-ocaml is not curated enough and lists things that are not stable nor usable, but at least it's a good step)


Le 27/08/2015 22:10, Yotam Barnoy a écrit :
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 <martindemello@gmail.com> wrote:
On Thu, Aug 27, 2015 at 3:35 AM, Romain Bardou <romain.bardou@inria.fr> 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


--------------070201020709060909080203--