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

[Yotam Barnoy <yotambarnoy@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3419 bytes --]

I'd like to mention the merits of not having a large standard library.
Consider the evolution of OCaml. Many of the paradigms with which OCaml was
born, such as using exceptions everywhere, have gone out of favor.
Hopefully, sometime in the near future, we'll have Modular Implicits
integrated into the language. Assuming this happens, it will almost
certainly impact what would be expected to belong in a standard library.
The official standard library already carries around with it vestigial
organs, such as the Stream module. This will only get worse if we add to it.

At the same time, I recognize a need for a library to represent a large
collection of data types and the functions over said types. It cannot all
be miniature libraries in opam IMO -- for basic programming, there should
be a curated source of basic and even some extended functionality.

What seems to me better than a built-in standard library, though, is a
reference to the best currently available libraries in each area, including
a 'standard' collection of utilities/data structures. Such a reference
could include space for the community to debate the pros and cons of
various libraries, and perhaps even a voting system to indicate to
potential users what the community thinks about said libraries. This is
something I currently have trouble with in opam, since I have no idea if a
given library is a) ancient and unmaintained b) the best in its class c)
rising in popularity d) written by a pro and solid, even if not used much.
The closest I have to that in opam is number of downloads, but given how
much the ecosystem now relies on opam, I think a more advanced display is
needed.

-Yotam

On Thu, Aug 27, 2015 at 3:55 PM, Martin DeMello <martindemello@gmail.com>
wrote:

> On Thu, Aug 27, 2015 at 3:35 AM, Romain Bardou <romain.bardou@inria.fr>
> wrote:
>>
>> I agree about smaller, independent packages. This is a very general API
>> design principle: avoid coupling (the fact that using a module implies
>> using another). This may be the main reason I avoid external libraries. For
>> instance, Martin Jambon's Yojson depends on biniou, cppo and easy-format. I
>> believe Martin is an awesome programmer but this particular point just
>> baffles me as there is absolutely no need for *any* external dependency to
>> solve such a simple problem (JSON parsing, pretty-printing and AST
>> constructors). I understand that Martin wants to reuse its own code and be
>> able to integrate Yojson easily with other libraries of his, and that is
>> great. For him and users of his other libraries. Not for those who just
>> want a JSON parser and have had to install all dependencies manually on
>> Windows.
>>
>
> Part of the promise of an ecosystem of small libraries is that you should
> be able to use them for any code you write, including other libraries. This
> is not the same thing as API coupling; as an end user of library C you
> should be able to use it without caring about whether it is self-contained
> in terms of code or whether it uses libraries A and B internally. The fact
> that dependencies need to be installed manually on windows is a failure of
> the ocaml windows ecosystem (which I'm definitely sympathetic towards; I
> once had to manually copy a bunch of code from batteries into my own
> project just to avoid depending on it); it is not a sign that libraries
> need not to depend on each other.
>
> martin
>

[-- Attachment #2: Type: text/html, Size: 4161 bytes --]