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 74B477EE34 for ; Sun, 27 Mar 2016 23:22:00 +0200 (CEST) IronPort-PHdr: 9a23:yiiPiBMQJRpMhAxObEAl6mtUPXoX/o7sNwtQ0KIMzox0KPj9rarrMEGX3/hxlliBBdydsKIUzbCN+Pm+ASQp2tWojjMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpQAbFhi3DwdpPOO9QteU1JTnkbrpsMSNO01hv3mUX/BbFF2OtwLft80b08NJC50a7V/3mEZOYPlc3mhyJFiezF7W78a0+4N/oWwL46pyv50IbaKvdK09SflcDS86G2Ez/szi8xfZHiWV4X5JaWQTlRwAKBLY5Rf3Rd+lqSr/sew70zOHNMv7VvZuAWz9x6I3WFnvkihRZG1xy33elsEl1PETmxmmvREqm4M= Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=Neutral smtp.pra=simon.cruanes.2007@m4x.org; spf=Pass smtp.mailfrom=SRS0=x+JG=PX=m4x.org=simon.cruanes.2007@bounces.m4x.org; spf=Pass smtp.helo=postmaster@mx1.polytechnique.org Received-SPF: Neutral (mail3-smtp-sop.national.inria.fr: domain of simon.cruanes.2007@m4x.org does not assert whether or not 129.104.30.34 is permitted sender) identity=pra; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=x+JG=PX=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="simon.cruanes.2007@m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of SRS0=x+JG=PX=m4x.org=simon.cruanes.2007@bounces.m4x.org designates 129.104.30.34 as permitted sender) identity=mailfrom; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=x+JG=PX=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="SRS0=x+JG=PX=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@mx1.polytechnique.org designates 129.104.30.34 as permitted sender) identity=helo; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=x+JG=PX=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="postmaster@mx1.polytechnique.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DLAgDXTfhWkyIeaIFTCYQBLk+vHI1lhxM8EAEBAQEBAQEBEAEBAQEJCwkJIS+CLYIUAQEBAwEjSxALCxEEAQEBCR4DAgIPBQ0lCSEUB4d3AwoIBAGwBYsjDYUQCIljf4I+gUgNgykrgisFlx0TKAgBhXGCcoMugWuCPYxYhzaHVTeCLhmBS2qIVgEBAQ X-IPAS-Result: A0DLAgDXTfhWkyIeaIFTCYQBLk+vHI1lhxM8EAEBAQEBAQEBEAEBAQEJCwkJIS+CLYIUAQEBAwEjSxALCxEEAQEBCR4DAgIPBQ0lCSEUB4d3AwoIBAGwBYsjDYUQCIljf4I+gUgNgykrgisFlx0TKAgBhXGCcoMugWuCPYxYhzaHVTeCLhmBS2qIVgEBAQ X-IronPort-AV: E=Sophos;i="5.24,402,1454972400"; d="asc'?scan'208";a="171157475" Received: from mx1.polytechnique.org ([129.104.30.34]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-GCM-SHA384; 27 Mar 2016 23:21:59 +0200 Received: from fuck_yeah.lan (4va54-h02-176-130-250-55.dsl.sta.abo.bbox.fr [176.130.250.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 9A6025647B6 for ; Sun, 27 Mar 2016 23:21:57 +0200 (CEST) Date: Sun, 27 Mar 2016 23:21:55 +0200 From: Simon Cruanes To: caml-list@inria.fr Message-ID: <20160327212155.GC29701@fuck_yeah.lan> References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> <06db01d1886a$e0b22fe0$a2168fa0$@ffconsultancy.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1SQmhf2mF2YjsYvc" Content-Disposition: inline In-Reply-To: <06db01d1886a$e0b22fe0$a2168fa0$@ffconsultancy.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Sun Mar 27 23:21:58 2016 +0200 (CEST)) X-Spam-Flag: No, tests=bogofilter, spamicity=0.000201, queueID=7A1E05647B7 X-Org-Mail: simon.cruanes.2007@polytechnique.org Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really --1SQmhf2mF2YjsYvc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le Sun, 27 Mar 2016, Jon Harrop a =C3=A9crit : > > I've found the (lack of) documentation to be a major blocker >=20 > You need Intellisense. Thanks to your intervention, I missed this thread last autumn. Indeed, containers is a one-man project, born of the same frustrations several people have expressed here. Unlike batteries or Core users, I kept using the standard library, which is why containers is a complement, not a replacement, to it. What I would *really* like, though, is being able to contribute some of the most central parts of containers to the standard library. I don't think maintaining a extended Option or List module takes a lot of effort to maintain (if the implementation is kept reasonably sane, and tests have been written) =E2=80=94 at least it doesn't take me a lot of time. Since I'm already in easter-level fantasy, I'd also like the standard library to provide more type definitions (similar to UChar or result) so th= at external, featurefull libraries can agree on them. In no particular order: datetime types, S-expressions, lazy lists, iterators (which should also be pervasive among existing modules)=E2=80=A6 Cheers, > From: hakuch@gmail.com [mailto:hakuch@gmail.com] On Behalf Of Jesse Haber= -Kucharsky > Sent: 27 August 2015 17:01 > To: Yaron Minsky > Cc: Hongbo Zhang; caml-list@inria.fr > Subject: Re: [Caml-list] We need a rich standard library distributed with= OCaml, really >=20 > To offer the perspective of a relative outsider who has meekly decided to= pipe in: >=20 > A standard library with a variety of general-purpose "building block" of = functionality is invaluable. I feel it's missing in OCaml. >=20 > Here is some important functionality that I'd like to see based on my own= experience writing a small-to-moderately sized OCaml program. >=20 > - Modules for standard types like `Int` and `Float` as previously mention= ed > - More standard definitions like `compose`, `const`, `identity`, etc (als= o as previously mentioned) > - Comprehensive string and regular expression handling (UTF support can b= e 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 ab= sence means that everyone will write their own, or that there will be hundr= eds in opam > - More immutable data structures like queues, heaps, stacks, etc > - A standard means of concurrency. Lwt is great, but is almost its own st= andard library at this point, and there's still a split between it and Asyn= c. > - Better support for error-handling-by-value with `either` and `option` t= hrough helper functions > - The ppx_deriving package reduces a TONNE of boilerplate for making defi= ning ordering on data for instance. It should be a standard extension (or s= omething like it) > - Better documentation/endorsement of build tools. It's possible to get p= retty far with ocamlbuild, _tags, and a simple Makefile, but figuring out h= ow to get there was not exactly easy > - Better interfaces to the file system with more structured error handlin= g on failure (`Sys_error` was not the nicest thing to work with). > - Less reliance on exceptions for non-exceptional situations and retrofit= ting "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 avoid= ed. >=20 > Finally, about the governance of such a library: >=20 > While libraries like Core and and Batteries are undeniably useful, I foun= d myself somewhat discouraged in practice: >=20 > - 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 usi= ng 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). >=20 > Best, > -- > Jesse >=20 >=20 > On Thu, Aug 27, 2015 at 10:17 AM, Yaron Minsky w= rote: > 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. >=20 > 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. >=20 > That said, I think I'd rather have the compiler folk work on improving > dead-code elimination than integrating and maintaining a standard > library. >=20 > 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. >=20 > y >=20 > On Wed, Aug 26, 2015 at 8:52 PM, Hongbo Zhang wr= ote: > > Dear OCaml developers, > > I would like to spend one hour in writing down my experience that w= hy 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 som= e 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 tha= t 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 implementati= on 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 pro= blem > > as batteries, a big dependency. There is a blocking issue, its developm= ent > > process is opaque, for an open source community, I would prefer a stand= ard > > 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 --=20 Simon Cruanes http://weusepgp.info/ key 49AA62B6, fingerprint 949F EB87 8F06 59C6 D7D3 7D8D 4AC0 1D08 49AA 62B6 --1SQmhf2mF2YjsYvc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW+E7yAAoJEErAHQhJqmK2ooQQAK0I8cfvmzzsaKa+i+/tMUQ4 3C30HZ0XpnoQx4nyzqqqUUXgIfepjVTWetPc1L1Ibzt+1y33JhsS9SLsUEmBClbv Mf8QlMkQZ6kXewpzMmKMI899xB9gdsqCD2cBddVx8Ijee/GPRjFOGBXDDL6CX3ht wmYfeT5qXJwRHX8CNVQ7eMVNphYgPZ4e4EmmcVpoWXOOaj3zQ4eKmRVXQ6q7UzbQ yz39HBd1+QVpy9MZtRAIYNQ7hYlkAzTKIoOL7TvvBF3HYqi7hbg0NAVklxSrgmWC lzwYu/GuKaNjNL5tkI+m/8/+R2/MKETLQt95uxxSY5hmqgYqdh6gWFQs0KPcO+1U +xaI+CdN1lUhWKRN5kzexLTDJCDBgVYi91+zEagmxWHf9dRaS03Q9iEpFrs1f2y0 vT/1t7YHe3g5Qo+SAu0Li9snpgvFcbmR/DTx6unvstX3lI1lWo4zHGNyG8mND52s ssrEQeAOxDt6L4lwjCyuCswIRJwN3MH2PmmPtcC2qCrDYmg+rR4kpc0iOiMTQuid 7U9X2FUelkmhZ5o2zg+YN0v3FVDLiwKXizslh8saNbSs0D1HRBS59dzaSbjfly1I FDNKu1KL/m5gMB5OABGptyhVdHf5IoyJjYLfuWStf4Za210Jp4voJ79L1O6YFJ09 mNPZc+TWbhlHvJMKjNcS =nhoe -----END PGP SIGNATURE----- --1SQmhf2mF2YjsYvc--