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

[Emmanuel Surleau <emmanuel.surleau@gmail.com>]

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

---------- Forwarded message ----------
From: Emmanuel Surleau <emmanuel.surleau@gmail.com>
Date: Thu, Aug 27, 2015 at 7:45 PM
Subject: Re: [Caml-list] We need a rich standard library distributed with
OCaml, really
To: Gabriel Scherer <gabriel.scherer@gmail.com>


Quoting Gabriel Scherer (2015-08-27 10:17:08)
> Hongbo, you are saying at the same time that:
> - you want a *rich* (in particular, large) standard library
> - existing third-party base libraries are too large for your taste
>
> If we magically imported one of those libraries in the OCaml
> distribution, it would still be large, and it would still have
> inter-dependencies between its modules. Why are you unwilling to
> depend on a library provided outside the distribution?
>
> Depending on external libraries used to be a problem when there was no
> consensus on OCaml packaging (no longer than a few years ago people
> where reluctant to even use ocamlfind). We now have a reasonable
> consensus on a packaging story, and installing third-party libraries
> has never been as easy as it is today -- except on Windows, meh.
> I think you should embrace the idea of depending on software outside
> the OCaml distribution.
>
> (I understand there are legal issues that make it difficult for some
> companies to use third-party software. It is not our job to work in
> stead of their lawyers.)
>
> Many of the issues people have with the library distributed with in
> the compiler distribution come from the fact that it is included in
> the compiler distribution -- and thus imposes a maintenance burden on
> the same group, same backward-compatibility constraints, etc. The
> general movements in the current years is to make the compiler
> distribution *smaller*, not *larger*, to avoid these problems.
>
>
> I think the criticism you make of existing standard library
> alternatives is fair (at least the Batteries part corresponds to
> something that I think is consensual¹). My preferred solution to help
> solve these issues is to contribute work to improve these libraries.
>
> ¹: Simon Cruanes has started good work to split Batteries in smaller
> modules that do not depend on each other. This effort is currently
> stalled, in large part by my personal fault (I was too
> perfectionist in hoping for doing this and at the same time preserving
> backward-functionality). Simon may have made the good call in starting
> his own parallel library effort suiting his relatively opinionated
> view of how things should be. I hope to get more time to devote to
> Batteries at some point, and resolve that tension by proposing a good
> compromise (integrating most of Simon's work) for a v3 release.
>
> There remain the issue that having several "base libraries" risks
> fragmenting the community in incompatible islands of software usage.
> It is true that shoving stuff into the compiler distribution is a way
> to resolve this excess of choice by authority, but it is manifest that
> no one currently wants to bear this authority and the responsibilities
> that come with it. (Except possibly on very localized issues, as the
> `result` type that is being integrated in 4.03+dev).
>
> I think the way forward is to have smaller independent packages that
> do not require so large a buy-in and consensus. We could have *one*
> package that provides many useful functions for lists, and one
> separate package with many useful functions for strings. In this style
> Daniel Bünzli beautifully documented small packages, or David Sheets
> doing-one-thing libraries would be role models to follow. This wasn't
> an option when Batteries or Core were started, because the packaging
> story was too confused, but it is now and we should take advantage of
> it. Given time (and help?) I hope to evolve Batteries towards this
> model.

(forwarding the original email to the list as I had sent only to Gabriel by
accident)

Well, as far collections go, you don't need "large libraries". You just
need a
to_gen method in collection types in the stdblib. The gen type itself
is trivially reimplementable, so it's not a hard dependency on ccube's gen
package, and gen itself is a single module that could, if there was the
will, be
integrated in the stdlib at little cost. This would greatly extend the
flexibility of existing data structures.

Another issue to consider is that you need to distinguish what is "sugar"
and
what is essential infrastructure. You do not want to farm out
infrastructure to
third parties. Otherwise, this puts maintainers of OCaml libraries in the
difficult position of choosing for their users. It's mostly a question of
data
types. If, for instance, the stdlib had sensible data types for handling
time
information, it would be acceptable to leave advanced time-handling
mechanics to
specialized libraries outside of the stdlib, as long as they were able to
rely
on a *lingua franca* of standard types.

Of course, all that wouldn't solve the design issues of the standard library
(eg, Str, exceptions everywhere, etc.), but adding gen (or at least hooks
for
gen) and a number of common data structures would really go a long way.

I wouldn't mind contributing a few hours working on that, assuming we could
reach some kind of consensus.

Cheers,

Emm

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