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

[Drup <drupyog+caml@zoho.com>]

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

https://github.com/rizo/awesome-ocaml ?

(my opinion is that awesome-ocaml is not curated enough and lists things 
that are not stable nor usable, but at least it's a good step)


Le 27/08/2015 22:10, Yotam Barnoy a écrit :
> 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 <mailto:martindemello@gmail.com>> wrote:
>
>     On Thu, Aug 27, 2015 at 3:35 AM, Romain Bardou
>     <romain.bardou@inria.fr <mailto: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: 6510 bytes --]