Re: [Caml-list] We need a rich standard library distributed with OCaml, really

[Yaron Minsky <yminsky@janestreet.com>]

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 <jon@ffconsultancy.com> 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 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 <yminsky@janestreet.com> 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 <bobzhang1988@gmail.com> 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 (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. batIO makes things even worse since it is not compatible with
>> standard library, some type signatures mismatched IIRC.
>>     - 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
> --
> 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