From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 756077EE34 for ; Mon, 28 Mar 2016 01:48:51 +0200 (CEST) IronPort-PHdr: 9a23:0tEgAxNrc9igHFdl0fQl6mtUPXoX/o7sNwtQ0KIMzox0KPv8rarrMEGX3/hxlliBBdydsKIUzbCN+PmwBiQp2tWojjMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpQAbFhi3DwdpPOO9QteU1JTnkbrpsMSDPE1hv3mUX/BbFF2OtwLft80b08NJC50a7V/3mEZOYPlc3mhyJFiezF7W78a0+4N/oWwL46pyv/h7TL7icq8kYbtdBTUgeyBptYy4/SXEGCmI4DM8W38MlQIAVwrC6jn0UJz2tDDnsvZ03iKLe8bxSOZndy6l6vJaQQXvjm8iNjgi83Cf3t11jaRAowOJpRV5zpXIeoyYKLx1eaaLLoBSfnZIQssED38JOYi7dYZaU7sM Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=yminsky@janestreet.com; spf=Pass smtp.mailfrom=yminsky@janestreet.com; spf=None smtp.helo=postmaster@mxout1.mail.janestreet.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.112 as permitted sender) identity=mailfrom; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mxout1.mail.janestreet.com) identity=helo; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@mxout1.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFAQAKcfhWjnDIaSZTCYQBLk8GqheEf41MIYVsAoEYBzwQAQEBAQEBAQEQAQEBAQcWCVCCLYIUAQEBBBIRHQEBLAsBDwsLBgQBAQECAgkaAwICIQESAQUBCgEJCAYTEgIHB4dwAxIDC6ItgTE+MYpPZ4RBAQSGWQMKhG4BAQEBAQEBAQEBAQEBAQEBAQEBARAGCnKFIoNFf4I+gUgNJ4MCglaGJwyQbxMxhXGGIIF1gjOMWIc2hhcRHoEPN4IhDREIgWVQiFYBAQE X-IPAS-Result: A0BFAQAKcfhWjnDIaSZTCYQBLk8GqheEf41MIYVsAoEYBzwQAQEBAQEBAQEQAQEBAQcWCVCCLYIUAQEBBBIRHQEBLAsBDwsLBgQBAQECAgkaAwICIQESAQUBCgEJCAYTEgIHB4dwAxIDC6ItgTE+MYpPZ4RBAQSGWQMKhG4BAQEBAQEBAQEBAQEBAQEBAQEBARAGCnKFIoNFf4I+gUgNJ4MCglaGJwyQbxMxhXGGIIF1gjOMWIc2hhcRHoEPN4IhDREIgWVQiFYBAQE X-IronPort-AV: E=Sophos;i="5.24,403,1454972400"; d="scan'208";a="210577961" Received: from mxout1.mail.janestreet.com ([38.105.200.112]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2016 01:48:45 +0200 Received: from tot-qpr-mailcore1.delacy.com ([172.27.56.68] helo=tot-qpr-mailcore1) by mxout1.mail.janestreet.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1akKQG-000520-4J for caml-list@inria.fr; Sun, 27 Mar 2016 19:48:44 -0400 X-JS-Flow: external Received: by tot-qpr-mailcore1 with JS-mailcore (0.1) (envelope-from ) id BW-HFc-AAACnV-Ct; 2016-03-27 19:48:44.088090-04:00 Received: from mail-qk0-f178.google.com ([209.85.220.178]) by mxgoog2.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1akKQF-00059T-UG for caml-list@inria.fr; Sun, 27 Mar 2016 19:48:44 -0400 Received: by mail-qk0-f178.google.com with SMTP id o6so91123179qkc.2 for ; Sun, 27 Mar 2016 16:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FBlddJM7tAabKA4OB3OAidWY7V2xcJQz45nSmkGRyuc=; b=fX0yZMROYaXXMXy1P2yCcvaSIP1Tp+Bm4ffK4TYTOP+7IG8yG7/8cDU3kL685bji03 vGNayfr/iZVWlaRb7j2cPkAzHBF70ZTJfDCXCdAe0ri8/3HRHrEHMwylJLQlwWvuR1ra LWKNrWI1AfWz2K8yAhrmQEF4LDP0idZ4pAm84= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FBlddJM7tAabKA4OB3OAidWY7V2xcJQz45nSmkGRyuc=; b=O5rvigk7bWc3ezE0jlrjZNcG1zsVrmBw6VWaJFv4qFAf0medqtC8DpMAhjLEdsIWa+ MjByi7ppCps8QZyKVvtcvEOmhXTk6D/lXURPh9bzTRmNlEFmBVqGAxhz9tdH43Zg6s3w ZuwdEGlFLJQtG9pJ2OSYxJMBPrVvethNhwQXART7SONU8nL1YkaTmL6EH2kMKPjR8sfC ifm46GcnPNJFaBkmArLZ1quJM7XuL/W93WqFXu2BusfH14AG0BvR1XVYCCbHGMtOmeir G1B04N+8d9uWMq5FoeyJ7LAk8jjHS7lbm1cOCXbjS8axsOA9j9FhEc31vuavGwumD4qH N5Nw== X-Gm-Message-State: AD7BkJKW3/ZLA/6OlIRIV2Wev5ziqfx63LReV91vlvzIoop51LXUbuuuf8piHgldlUdLAktyzkxoAZyJVcs2boEGzfZZGiSgUVFGdS9/SgeKN3uHbS7Bp1cXNLHi38IInu95I0FnxTojTLjOLOlD X-Received: by 10.37.85.213 with SMTP id j204mr11610417ybb.97.1459122523629; Sun, 27 Mar 2016 16:48:43 -0700 (PDT) X-Received: by 10.37.85.213 with SMTP id j204mr11610407ybb.97.1459122523335; Sun, 27 Mar 2016 16:48:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.226.65 with HTTP; Sun, 27 Mar 2016 16:48:23 -0700 (PDT) In-Reply-To: <06db01d1886a$e0b22fe0$a2168fa0$@ffconsultancy.com> References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> <06db01d1886a$e0b22fe0$a2168fa0$@ffconsultancy.com> From:Yaron Minsky Date: Sun, 27 Mar 2016 19:48:23 -0400 Message-ID: To:Jon Harrop Cc:"caml-list@inria.fr" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-JS-Processed-by: mailcore Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really Merlin is actually pretty great for this! It provides auto-completion, type throwback, documentation throwback, go-to-definition, and a few other nice features. It's worth checking out. y On Sun, Mar 27, 2016 at 4:54 PM, Jon Harrop wrote: > 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= -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 > > 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 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. > > Finally, about the governance of such a library: > > While libraries like Core and and Batteries are undeniably useful, I foun= d 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 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). > > Best, > -- > Jesse > > > 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. > > 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 wr= ote: >> Dear OCaml developers, >> I would like to spend one hour in writing down my experience that wh= y 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 strin= gs 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 s= ure >> 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 o= wn 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 libra= ries, 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 (OCam= l 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 implementatio= n 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 prob= lem >> as batteries, a big dependency. There is a blocking issue, its developme= nt >> process is opaque, for an open source community, I would prefer a standa= rd >> 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 > > > > -- > 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