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 C1BCC7F168 for ; Thu, 27 Aug 2015 18:01:10 +0200 (CEST) IronPort-PHdr: 9a23:U4YOvxJM52zAvRABmdmcpTZWNBhigK39O0sv0rFitYgVK/zxwZ3uMQTl6Ol3ixeRBMOAu6kC1bad4v2ocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC1ILpi6vjptX6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFm0vb2rgHORhej4X4VU2Ne0kYZQluN0Bavb57rtS2yk+t7wyqLdZnnSLEyQjezx6ViThLzlD0KOiJ/+2bS3J9elqVe9TCsvAdyi67daoyPcdljdaPUZ8gZVCIVXMtKTCFpAoq2YpEMEuEBNPxDrJi7rFwL+0jtTTKwDf/in2cbzkT92rc3hqF8SAw= Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=hakuch@gmail.com; spf=Pass smtp.mailfrom=hakuch@gmail.com; spf=None smtp.helo=postmaster@mail-qg0-f44.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of hakuch@gmail.com) identity=pra; client-ip=209.85.192.44; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="hakuch@gmail.com"; x-sender="hakuch@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of hakuch@gmail.com designates 209.85.192.44 as permitted sender) identity=mailfrom; client-ip=209.85.192.44; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="hakuch@gmail.com"; x-sender="hakuch@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-qg0-f44.google.com) identity=helo; client-ip=209.85.192.44; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="hakuch@gmail.com"; x-sender="postmaster@mail-qg0-f44.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CFBgDlMt9VlCzAVdFVCYNvLAE8BoMdgQepBJAfgiyFe4EvBzwQAQEBAQEBAQEQAQEBAQcLCwkfMIIdggYBAQEDARIRHQEtCwEDAQsBBQMCCwMKDR0CAiEBEgEFAQoSBhMSAgcHh3cDCggNlWCPP4EvPjGLQIRlikwnAwqFFwsBAQEYAQUOhFKFfoEDgk+BUw1YgnSBQwWFdAyPAD2FBoYAgW2CEJEVhW8SI4EXEQZJgVUcgXAiM4JNAQEB X-IPAS-Result: A0CFBgDlMt9VlCzAVdFVCYNvLAE8BoMdgQepBJAfgiyFe4EvBzwQAQEBAQEBAQEQAQEBAQcLCwkfMIIdggYBAQEDARIRHQEtCwEDAQsBBQMCCwMKDR0CAiEBEgEFAQoSBhMSAgcHh3cDCggNlWCPP4EvPjGLQIRlikwnAwqFFwsBAQEYAQUOhFKFfoEDgk+BUw1YgnSBQwWFdAyPAD2FBoYAgW2CEJEVhW8SI4EXEQZJgVUcgXAiM4JNAQEB X-IronPort-AV: E=Sophos;i="5.17,422,1437429600"; d="scan'208";a="143989091" Received: from mail-qg0-f44.google.com ([209.85.192.44]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 27 Aug 2015 18:01:08 +0200 Received: by qgeh99 with SMTP id h99so15183065qge.0 for ; Thu, 27 Aug 2015 09:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=QK32SoyX87oG1u7L1VGpAk2wsXv11pg553E/xCaYWbY=; b=nbuCbdt9SDpjt1Rgg6NXYF8sWpUnLYebMsyJrCbKz+5lFLkTt1ag+QOIypSo2G704A EmrNk+UxvKZuVyqoBOa532zocrpjV97GnOj/Gy3Z38Ghb5h7susBo1DJaeiPblrkuoWN QhYAfBmiUsk+TzD01qAqFr2946lk4Gbgx3jJ/pfTW5QB2E+ajdVWle2gXtpIeLTg5hku PRBX0lOyn43viEZyyH5mUZ/UssjDnvTVcILf7Cj4GELPVbmE6HNr2UKHAZ0wpDb9X6I6 bmvfZ4wZTII4driUXFGzXf7SsRVPjdOhzysF/F+eZIZpMDFF5O/An9+nFfx5JNVW+5W5 +S5A== X-Received: by 10.140.233.210 with SMTP id e201mr8280233qhc.88.1440691267774; Thu, 27 Aug 2015 09:01:07 -0700 (PDT) MIME-Version: 1.0 Sender: hakuch@gmail.com Received: by 10.55.21.141 with HTTP; Thu, 27 Aug 2015 09:00:48 -0700 (PDT) In-Reply-To: References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> From: Jesse Haber-Kucharsky Date: Thu, 27 Aug 2015 12:00:48 -0400 X-Google-Sender-Auth: 8SCI3OSkFE7E61Tzi2Meuwpyy_4 Message-ID: To: Yaron Minsky Cc: Hongbo Zhang , "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a113545203f4680051e4d13c5 Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really --001a113545203f4680051e4d13c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To offer the perspective of a relative outsider who has meekly decided to pipe in: A standard library with a variety of general-purpose "building block" of functionality is invaluable. I feel it's missing in OCaml. Here is some important functionality that I'd like to see based on my own experience writing a small-to-moderately sized OCaml program. - Modules for standard types like `Int` and `Float` as previously mentioned - More standard definitions like `compose`, `const`, `identity`, etc (also as previously mentioned) - Comprehensive string and regular expression handling (UTF support can be relegated to an endorsed third party package) - More helper functions in the `List` and `Option` modules - A standard general purpose lazy list (stream). I was able to implement this comprehensively in about 300 lines, and its enormously useful. It's absence means that everyone will write their own, or that there will be hundreds in opam - More immutable data structures like queues, heaps, stacks, etc - A standard means of concurrency. Lwt is great, but is almost its own standard library at this point, and there's still a split between it and Async. - Better support for error-handling-by-value with `either` and `option` through helper functions - The ppx_deriving package reduces a TONNE of boilerplate for making defining ordering on data for instance. It should be a standard extension (or something like it) - Better documentation/endorsement of build tools. It's possible to get pretty far with ocamlbuild, _tags, and a simple Makefile, but figuring out how to get there was not exactly easy - Better interfaces to the file system with more structured error handling on failure (`Sys_error` was not the nicest thing to work with). - Less reliance on exceptions for non-exceptional situations and retrofitting "pure" functions like `hd` with `option` or `either` result types. - Less duplication and or more aggressive deprecation. It's not clear to me why there should be both "Foo" and "FooLabels" modules, for instance. I also hear that some modules in the standard library are probably best avoided. Finally, about the governance of such a library: While libraries like Core and and Batteries are undeniably useful, I found myself somewhat discouraged in practice: - Batteries has relatively low adoption and I think it does too much - Core is driven by a private organization. In practise, I've found the (lack of) documentation to be a major blocker, and I'd feel better about using it if it was truly community "owned" (or if there was a non-profit spin-off to support and own it like the F# foundation, for instance). Best, -- Jesse On Thu, Aug 27, 2015 at 10:17 AM, Yaron Minsky wrote: > The core OCaml team is small, and having them focused on building a > great compiler rather than on building a rich stdlib seems right to > me. The improvements in packaging I think make the question of > whether it's distributed with the compiler mostly a moot issue, I > think. > > On the topic of Core: The issue of binary size is real. It will get > somewhat better when we drop packed modules from the public release, > which should come in the next few months (support for it internally is > mostly in place.) That said the module-level dependency tracking is > by its nature coarse, so binaries using Core (or the more portable > Core_kernel) are still going to be relatively large. > > That said, I think I'd rather have the compiler folk work on improving > dead-code elimination than integrating and maintaining a standard > library. > > As to openness: we publish all changes on github, have a mailing list, > and will accept pull requests; but it's true that the development of > Core is focused within Jane Street, and that is unlikely to change. > > y > > On Wed, Aug 26, 2015 at 8:52 PM, 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 functi= on > > =E2=80=9CString.split=E2=80=9D which split a string into a list of stri= ngs 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 batterie= s, > > batteries is too big for my projects. `BatString.nsplit` seems to fit f= or > > 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 anoth= er > > module `BatReturn`, then I stopped here, it=E2=80=99s 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=E2=80= =99t do > > anything. > > Note that I don=E2=80=99t want to be offensive to any of these libr= aries, > 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=E2=80=99s big with dependencies between different modules (OCa= ml 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. batIO makes things even worse since it is not compatible with > > standard library, some type signatures mismatched IIRC. > > - ocaml-containers > > Mostly one man=E2=80=99s 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 =E2=80=94 Hongbo > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --001a113545203f4680051e4d13c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To offer the perspective of a relative outsider who has me= ekly decided to pipe in:

A standard library with a varie= ty of general-purpose "building block" of functionality is invalu= able. I feel it's missing in OCaml.

Here is so= me important functionality that I'd like to see based on my own experie= nce writing a small-to-moderately sized OCaml program.

=
- Modules for standard types like `Int` and `Float` as previously ment= ioned
- More standard definitions like `compose`, `const`, `ident= ity`, etc (also as previously mentioned)
- Comprehensive string a= nd regular expression handling (UTF support can be relegated to an endorsed= third party package)
- More helper functions in the `List` and `= Option` modules
- A standard general purpose lazy list (stream). = I was able to implement this comprehensively in about 300 lines, and its en= ormously useful. It's absence means that everyone will write their own,= or that there will be hundreds in opam
- More immutable data str= uctures like queues, heaps, stacks, etc
- A standard means of con= currency. Lwt is great, but is almost its own standard library at this poin= t, and there's still a split between it and Async.
- Better s= upport for error-handling-by-value with `either` and `option` through helpe= r functions
- The ppx_deriving package reduces a TONNE of boilerp= late for making defining ordering on data for instance. It should be a stan= dard extension (or something like it)
- Better documentation/endo= rsement of build tools. It's possible to get pretty far with ocamlbuild= , _tags, and a simple Makefile, but figuring out how to get there was not e= xactly easy
- Better interfaces to the file system with more stru= ctured error handling on failure (`Sys_error` was not the nicest thing to w= ork with).
- Less reliance on exceptions for non-exceptional situ= ations and retrofitting "pure" functions like `hd` with `option` = or `either` result types.
- Less duplication and or more aggressi= ve deprecation. It's not clear to me why there should be both "Foo= " and "FooLabels" modules, for instance. I also hear that so= me modules in the standard library are probably best avoided.
Finally, about the governance of such a library:

=
While libraries like Core and and Batteries are undeniably usefu= l, I found myself somewhat discouraged in practice:

- Batteries has relatively low adoption and I think it does too much
- Core is driven by a private organization. In practise, I've fou= nd the (lack of) documentation to be a major blocker, and I'd feel bett= er about using it if it was truly community "owned" (or if there = was a non-profit spin-off to support and own it like the F# foundation, for= instance).

Best,
--
Jesse


= On Thu, Aug 27, 2015 at 10:17 AM, Yaron Minsky <yminsky@janestreet.co= m> wrote:
The core OCaml te= am is small, and having them focused on building a
great compiler rather than on building a rich stdlib seems right to
me.=C2=A0 The improvements in packaging I think make the question of
whether it's distributed with the compiler mostly a moot issue, I
think.

On the topic of Core: The issue of binary size is real.=C2=A0 It will get somewhat better when we drop packed modules from the public release,
which should come in the next few months (support for it internally is
mostly in place.)=C2=A0 That said the module-level dependency tracking is by its nature coarse, so binaries using Core (or the more portable
Core_kernel) are still going to be relatively large.

That said, I think I'd rather have the compiler folk work on improving<= br> dead-code elimination than integrating and maintaining a standard
library.

As to openness: we publish all changes on github, have a mailing list,
and will accept pull requests; but it's true that the development of
Core is focused within Jane Street, and that is unlikely to change.

y

On Wed, Aug 26, 2015 at 8:52 PM, Hongbo Zhang <bobzhang1988@gmail.com> wrote:
> Dear OCaml developers,
>=C2=A0 =C2=A0 =C2=A0I would like to spend one hour in writing down my e= xperience 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.
>=C2=A0 =C2=A0 =C2=A0I am doing some compiler hacking tonight, I needed = a utility function
> =E2=80=9CString.split=E2=80=9D which split a string into a list of str= ings by whitespace, it
> is just one liner if you use str library. However, since I am doing so= me low
> level stuff, I would try to avoid such big dependency, and I am pretty= sure
> that I have ever written it=C2=A0 for at least three times, I just hop= ed that I
> could get it done quickly, so I am looking into batteries that if I ca= n
> steal some code, I have to copy some code instead of depend on batteri= es,
> 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 t= he
> whole module `BatString` into REPL, still no luck, it depended on anot= her
> module `BatReturn`, then I stopped here, it=E2=80=99s time to write my= own ad-hoc
> thrown-away `String.split` function again.
>=C2=A0 =C2=A0 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 hav= e four
> *standard libraries* alternatives: batteries, core, extlib and
> ocaml-containers. In my opinion, none of them matches the beauty of th= e
> OCaml language itself and probably will never catch up if we don=E2=80= =99t do
> anything.
>=C2=A0 =C2=A0 =C2=A0Note that I don=E2=80=99t want to be offensive to a= ny of these libraries, just
> my personal feedback that why I think it is not a good standard librar= y, I
> appreciated a lot to people who contribute their precious time in
> maintaining these libraries, better than nothing : )
>=C2=A0 =C2=A0 =C2=A0- Batteries(extlib)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0It=E2=80=99s big with dependencies between d= ifferent modules (OCaml does not
> have a good story in dead code elimination), some of its modules are o= f low
> quality, for example, batEnum is used everywhere while its implementat= ion is
> buggy. batIO makes things even worse since it is not compatible with > standard library, some type signatures mismatched IIRC.
>=C2=A0 =C2=A0 =C2=A0- ocaml-containers
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Mostly one man=E2=80=99s project
>=C2=A0 =C2=A0 =C2=A0- core
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I believe core has high quality, however, it= suffers the same problem
> as batteries, a big dependency. There is a blocking issue, its develop= ment
> process is opaque, for an open source community, I would prefer a stan= dard
> library developed in an open environment.
>=C2=A0 =C2=A0 =C2=A0I am not expecting that we could have a=C2=A0 stand= ard library as rich as
> python, but for some utilities, I do believe that shipped with standar= d
> library or officially supported is the best solution.
>=C2=A0 =C2=A0 Thanks =E2=80=94 Hongbo

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocam= l_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--001a113545203f4680051e4d13c5--