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 C8F207F0D9 for ; Thu, 27 Aug 2015 10:12:55 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.17,421,1437429600"; d="scan'208";a="143923460" Received: from meleze.ens.fr (HELO [129.199.99.114]) ([129.199.99.114]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 27 Aug 2015 10:12:55 +0200 To: caml-list@inria.fr References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> From: Francois Berenger Message-ID: <55DEC687.5050201@inria.fr> Date: Thu, 27 Aug 2015 10:12:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really On 08/27/2015 04:52 AM, Hongbo Zhang wrote: > Dear OCaml developers, > I would like to spend one hour in writing down my experience that > why I had to write some small utilities again and again, since this > happened so many times that I believe you might come across such issues > before. > I am doing some compiler hacking tonight, I needed a utility > function “String.split” which split a string into a list of strings by > whitespace, it is just one liner if you use str library. However, since > I am doing some low level stuff, I would try to avoid such big > dependency, and I am pretty sure that I have ever written it for at > least three times, I just hoped that I could get it done quickly, so I > am looking into batteries that if I can steal some code, I have to copy > some code instead of depend on batteries, batteries is too big for my > projects. `BatString.nsplit` seems to fit for what I needed, I copied > the definition of `BatString.nsplit` into REPL, no luck, it depends on > some previously defined functions, then I copied the whole module > `BatString` into REPL, still no luck, it depended on another module > `BatReturn`, then I stopped here, it’s time to write my own ad-hoc > thrown-away `String.split` function again. > OCaml is my favorite programming language, and I am very productive > at it, however, I was annoyed by such things from time to time. We do > have four *standard libraries* alternatives: batteries, core, extlib and > ocaml-containers. In my opinion, none of them matches the beauty of the > OCaml language itself and probably will never catch up if we don’t do > anything. > Note that I don’t want to be offensive to any of these libraries, > just my personal feedback that why I think it is not a good standard > library, */I appreciated a lot to people who contribute their precious > time in maintaining these libraries, better than nothing/* : ) > - Batteries(extlib) > It’s big with dependencies between different modules For batteries, there is a very interesting proposal from Simon Cruanes (a batteries contributor and also the author of ocaml-containers) about cutting batteries into small pieces. https://github.com/ocaml-batteries-team/batteries-included/pull/554 > (OCaml does > not have a good story in dead code elimination), some of its modules are > of low quality, for example, batEnum is used everywhere while its > implementation is buggy. If we cut into small pieces, maybe we should adopt list and arrays as the "glue" to interchange data between modules. So you can really depend on a single module, if you want to. > batIO makes things even worse since it is not > compatible with standard library, some type signatures mismatched IIRC. batIO even introduce a performance regression bug compared to the stdlib. But, it is also easy to avoid; you can always tap into Legacy.* to access the stdlib things and avoid the batIO layer (when you have a 'open Batteries' at the top of your file). > - ocaml-containers > Mostly one man’s project > - core > I believe core has high quality, however, it suffers the same > problem as batteries, a big dependency. There is a blocking issue, its > development process is opaque, for an open source community, I would > prefer a standard library developed in an open environment. > I am not expecting that we could have a standard library as rich > as python, but for some utilities, I do believe that shipped with > standard library or officially supported is the best solution. > Thanks — Hongbo -- Regards, Francois. "When in doubt, use more types"