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 E1B487EE34 for ; Sun, 27 Mar 2016 22:54:22 +0200 (CEST) IronPort-PHdr: 9a23:gK3HtBH6ATb2C+FFqZZ1Np1GYnF86YWxBRYc798ds5kLTJ75rsiwAkXT6L1XgUPTWs2DsrQf27qQ6furADFfqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh7D0ocaYOlgXzBOGIppMbzyO5T3LsccXhYYwYo0Q8TDu5kVyRuJN2GlzLkiSlRuvru25/Zpk7jgC86l5r50IZ57nZLw1RqB0CzEvMmZ9pJG69EqLcQzasnAVV2FTlhtTHyDE6gv7V9H/qH2pjOdl3DimOpiiT7cycTqs5KBtUwLslC4BPC9/+2bS3J9elqVe9ViDoBo344fOeoaNfrIqfKTbVd0UTm1HRdtVSyVHCZL6ZIwKWblSdd1EppXw8gNd5SC1AhOhUb++xw== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=jon@ffconsultancy.com; spf=None smtp.mailfrom=jon@ffconsultancy.com; spf=None smtp.helo=postmaster@avasout06.plus.net Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of jon@ffconsultancy.com) identity=pra; client-ip=212.159.14.18; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="jon@ffconsultancy.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of jon@ffconsultancy.com) identity=mailfrom; client-ip=212.159.14.18; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="jon@ffconsultancy.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@avasout06.plus.net) identity=helo; client-ip=212.159.14.18; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="postmaster@avasout06.plus.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOAgDvR/hWjBIOn9RTCYQBLk+qHYR/jUwXCoVsAoEdPBABAQEBAQEBARABAQEIDQkJHzGCLYIUAQEBBAgCGUsYAwIJEQQBAQECAgkaAwICGQgbCQEJCAIEEwsFAgIHh3cDFgqveYYhhQIDCoRuAQsBHXyIZ3+CPoFIDYJxOBOCQwWGIgyMWIQXEzEBgVSEHIYghCiMWIc2h1U3gi4RCIFKa4hWAQEB X-IPAS-Result: A0DOAgDvR/hWjBIOn9RTCYQBLk+qHYR/jUwXCoVsAoEdPBABAQEBAQEBARABAQEIDQkJHzGCLYIUAQEBBAgCGUsYAwIJEQQBAQECAgkaAwICGQgbCQEJCAIEEwsFAgIHh3cDFgqveYYhhQIDCoRuAQsBHXyIZ3+CPoFIDYJxOBOCQwWGIgyMWIQXEzEBgVSEHIYghCiMWIc2h1U3gi4RCIFKa4hWAQEB X-IronPort-AV: E=Sophos;i="5.24,402,1454972400"; d="scan'208";a="171155187" Received: from avasout06.plus.net ([212.159.14.18]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 27 Mar 2016 22:54:21 +0200 Received: from XPS ([91.125.45.70]) by avasout06 with smtp id b8uH1s0031WqrlX018uJVQ; Sun, 27 Mar 2016 21:54:19 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=Rr04V3SK c=1 sm=1 tr=0 a=2LPH7kyaFZ6h6aa0GN6Tug==:117 a=2LPH7kyaFZ6h6aa0GN6Tug==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=pGLkceISAAAA:8 a=h6pNz4pCAAAA:8 a=ZOzjf2MOAAAA:8 a=CjxXgO3LAAAA:8 a=LEjnXA_L1dRTtAV-6PcA:9 a=FTmqEj8sAQxscYGi:21 a=WYTjlmpHjfjXEUiu:21 a=QEXdDO2ut3YA:10 X-AUTH: jdh302@:2500 Reply-To: From: "Jon Harrop" To: References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> In-Reply-To: Date: Sun, 27 Mar 2016 21:54:37 +0100 Organization: Flying Frog Consultancy Ltd. Message-ID: <06db01d1886a$e0b22fe0$a2168fa0$@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGglZnl3JclI+5Fy9R04thyZZU9gH/NcNBAhXWwhye4yfi0A== Content-Language: en-gb Subject: RE: [Caml-list] We need a rich standard library distributed with OCaml, really Jesse Haber-Kucharsky wrote: > I've found the (lack of) documentation to be a major blocker You need Intellisense. Cheers, Jon. From: hakuch@gmail.com [mailto:hakuch@gmail.com] On Behalf Of Jesse Haber-K= ucharsky 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 O= Caml, really To offer the perspective of a relative outsider who has meekly decided to p= ipe in: A standard library with a variety of general-purpose "building block" of fu= nctionality is invaluable. I feel it's missing in OCaml. Here is some important functionality that I'd like to see based on my own e= xperience 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 th= is comprehensively in about 300 lines, and its enormously useful. It's abse= nce means that everyone will write their own, or that there will be hundred= s in opam - More immutable data structures like queues, heaps, stacks, etc - A standard means of concurrency. Lwt is great, but is almost its own stan= dard 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` thr= ough helper functions - The ppx_deriving package reduces a TONNE of boilerplate for making defini= ng ordering on data for instance. It should be a standard extension (or som= ething like it) - Better documentation/endorsement of build tools. It's possible to get pre= tty 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 retrofitti= ng "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 al= so 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 (la= ck 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-of= f to support and own it like the F# foundation, for instance). Best, -- Jesse On Thu, Aug 27, 2015 at 10:17 AM, Yaron Minsky wro= te: 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 wrot= e: > 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 > =E2=80=9CString.split=E2=80=9D which split a string into a list of string= s 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 su= re > 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=E2=80=99s time to write my ow= n 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 f= our > *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=99= t do > anything. > Note that I don=E2=80=99t want to be offensive to any of these librar= ies, 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 (OCaml= does not > have a good story in dead code elimination), some of its modules are of l= ow > 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 probl= em > 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