caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Francois Berenger <francois.berenger@inria.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really
Date: Thu, 27 Aug 2015 10:12:55 +0200	[thread overview]
Message-ID: <55DEC687.5050201@inria.fr> (raw)
In-Reply-To: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com>

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"

  parent reply	other threads:[~2015-08-27  8:12 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-27  2:52 Hongbo Zhang
2015-08-27  6:59 ` Christoph Höger
2015-08-27  7:18 ` Anthony Tavener
2015-08-27  8:17   ` Gabriel Scherer
2015-08-27 10:35     ` Romain Bardou
2015-08-27 19:55       ` Martin DeMello
2015-08-27 20:10         ` Yotam Barnoy
2015-08-27 23:24           ` Drup
2015-08-28 13:23           ` Philippe Veber
2015-08-27 20:17         ` Raoul Duke
2015-08-27 23:10       ` Martin Jambon
     [not found]     ` <20150827174554.14858.6618@localhost>
2015-08-27 18:42       ` [Caml-list] Fwd: " Emmanuel Surleau
2015-08-27 21:17     ` [Caml-list] " Paolo Donadeo
2015-08-27 21:51       ` Oliver Bandel
2015-08-27 21:56         ` Oliver Bandel
2015-08-27 22:04           ` Oliver Bandel
2015-08-28  0:50     ` Hongbo Zhang
2015-08-31 16:06     ` Stéphane Glondu
2015-08-31 16:14       ` Francois Berenger
2015-08-31 16:44         ` Hendrik Boom
2015-08-31 18:04           ` Ian Zimmerman
2015-08-31 17:26         ` Stéphane Glondu
2015-09-01 15:06           ` Anil Madhavapeddy
2015-08-31 17:34       ` Oliver Bandel
2015-09-01 13:46       ` Gabriel Scherer
2015-08-27  8:07 ` Sébastien Hinderer
2015-08-27  8:20   ` Daniil Baturin
2015-08-27  9:34     ` Edouard Evangelisti
2015-08-28  9:07       ` r.3
2015-08-27  8:12 ` Francois Berenger [this message]
2015-08-27 11:57   ` Drup
2015-08-27 14:17 ` Yaron Minsky
2015-08-27 16:00   ` Jesse Haber-Kucharsky
2015-08-28  0:33     ` Hongbo Zhang
2015-08-28  1:53       ` Daniel Bünzli
     [not found]       ` <20150828.140826.2157566405742612169.Christophe.Troestler@umons.ac.be>
2015-08-28 12:38         ` Thomas Braibant
2015-08-28 13:00           ` [Caml-list] opam license field (was Re: We need a rich standard library distributed with OCaml, really) Daniel Bünzli
2015-08-28 13:06             ` David Sheets
2015-08-28 14:01         ` [Caml-list] We need a rich standard library distributed with OCaml, really Oliver Bandel
2015-08-31 15:26           ` Hendrik Boom
2015-08-28 14:35         ` Alain Frisch
2015-08-29 19:02           ` David MENTRÉ
2015-08-31 12:37             ` Jon Harrop
2015-08-31 15:05               ` Emmanuel Surleau
2015-08-31 17:31                 ` Oliver Bandel
2015-08-28 15:02         ` Simon Cruanes
2015-08-28 15:27           ` Gabriel Scherer
2015-08-28 15:51         ` Oliver Bandel
2015-08-31 18:40       ` Ashish Agarwal
2016-03-27 20:54     ` Jon Harrop
2016-03-27 21:21       ` Simon Cruanes
2016-03-27 23:48       ` Yaron Minsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55DEC687.5050201@inria.fr \
    --to=francois.berenger@inria.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).