From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr 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 49C447F168 for ; Thu, 27 Aug 2015 20:42:33 +0200 (CEST) IronPort-PHdr: 9a23:AvQF6hU1tZseOLrju6A+mCbDKYzV8LGtZVwlr6E/grcLSJyIuqrYZhCOt8tkgFKBZ4jH8fUM07OQ6PC7HzJcqs/b7jgrS99laVwssY0uhQsuAcqIWwXQDcXBSGgEJvlET0Jv5HqhMEJYS47UblzWpWCuv3ZJQk2sfTR8Kum9IIPOlcP/j7n0oM2IJVsUz2PnP/tbF1afk0b4joEum4xsK6I8mFPig0BjXKBo/15uPk+ZhB3m5829r9ZJ+iVUvO89pYYbCf2pN/dwcbsNBz0jNyUx5db3nRjFVwqGoHUGAUsMlR8dLg3A5RfnU5O5iTbgsud0xWHOMMjzRLYpVDDk9LpxTBLhlQ8IMjc49Cfcjckm3/ETmw6ouxEqm92cW4qSLvcrJq4= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=emmanuel.surleau@gmail.com; spf=Pass smtp.mailfrom=emmanuel.surleau@gmail.com; spf=None smtp.helo=postmaster@mail-qk0-f178.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of emmanuel.surleau@gmail.com) identity=pra; client-ip=209.85.220.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="emmanuel.surleau@gmail.com"; x-sender="emmanuel.surleau@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of emmanuel.surleau@gmail.com designates 209.85.220.178 as permitted sender) identity=mailfrom; client-ip=209.85.220.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="emmanuel.surleau@gmail.com"; x-sender="emmanuel.surleau@gmail.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@mail-qk0-f178.google.com) identity=helo; client-ip=209.85.220.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="emmanuel.surleau@gmail.com"; x-sender="postmaster@mail-qk0-f178.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C2AQAGWd9VnLLcVdFehFgGwjmDOAKBLgc8EAEBAQEBAQEBEAEBAQEBBg0JCSEugh2CBgEBAQMBEhEdARseAwELBhAGAwECKwICIQEBEQEFARICCBkIDAcHh3YBAwoIpRiBLz4xi0CBbIJ5iiYKGScNVoRBAQEIAQEBARgBBQ6LU4JPgVMGEQFAGAaCY4FDBYcqjhOLBoFtgUqRXINQgh8SI4EXF4QQPDOBDoE/AQEB X-IPAS-Result: A0C2AQAGWd9VnLLcVdFehFgGwjmDOAKBLgc8EAEBAQEBAQEBEAEBAQEBBg0JCSEugh2CBgEBAQMBEhEdARseAwELBhAGAwECKwICIQEBEQEFARICCBkIDAcHh3YBAwoIpRiBLz4xi0CBbIJ5iiYKGScNVoRBAQEIAQEBARgBBQ6LU4JPgVMGEQFAGAaCY4FDBYcqjhOLBoFtgUqRXINQgh8SI4EXF4QQPDOBDoE/AQEB X-IronPort-AV: E=Sophos;i="5.17,422,1437429600"; d="scan'208";a="175103867" Received: from mail-qk0-f178.google.com ([209.85.220.178]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 27 Aug 2015 20:42:31 +0200 Received: by qkda128 with SMTP id a128so15568795qkd.3 for ; Thu, 27 Aug 2015 11:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WXn7Cgpr8F9pVwPiHernfqbq4UYS6fYwWfGG7nDf5kA=; b=ZQnFbn0OEJ73jgaO2ssnYIlI7tWNYXel+AYPqPerlQYzX7LidXluaVkOgH5gGF6Fuu WFW80V0GaFUnZ2c5LHULg4AOxU4j6qUC6rUiguAFIbWH194Ch08WWxO9yT7LLyrLGQQ4 6AtSiZq2yNgZImgk8CES31Au1HugR/tqpAc7+mJ4ZAL5QtRCMfpUmWtwB/4e6QNQ8YTF JqDg9LqCyV4grVfAsI0E+TITpqf4rO7elSlD9eXVMUxDqJu8dyHGMVk4nVpKP9F9h4o/ o1BF1VUY6jEgTxuACkraVrWheDknocQp1cQ8FT4qYoVHyoxivCYq2ePRuAqSz7NhjR1C OhrA== MIME-Version: 1.0 X-Received: by 10.55.221.8 with SMTP id n8mr9423538qki.85.1440700950941; Thu, 27 Aug 2015 11:42:30 -0700 (PDT) Received: by 10.55.19.216 with HTTP; Thu, 27 Aug 2015 11:42:30 -0700 (PDT) In-Reply-To: <20150827174554.14858.6618@localhost> References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> <20150827174554.14858.6618@localhost> Date: Thu, 27 Aug 2015 20:42:30 +0200 Message-ID: From: Emmanuel Surleau To: caml-list@inria.fr Content-Type: multipart/alternative; boundary=001a1149d300689469051e4f54fb Subject: [Caml-list] Fwd: We need a rich standard library distributed with OCaml, really --001a1149d300689469051e4f54fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- From: Emmanuel Surleau 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 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=C2=B9). My preferred solution to help > solve these issues is to contribute work to improve these libraries. > > =C2=B9: 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=C3=BCnzli 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 --001a1149d300689469051e4f54fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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


Quoting Gabriel Scher= er (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<= br> > 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=C2=B9). My preferred solution to = help
> solve these issues is to contribute work to improve these libraries. >
> =C2=B9: Simon Cruanes has started good work to split Batteries in smal= ler
> 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<= br> > 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<= br> > 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=C3=BCnzli beautifully documented small packages, or David She= ets
> doing-one-thing libraries would be role models to follow. This wasn= 9;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<= br> > it. Given time (and help?) I hope to evolve Batteries towards this
> model.

(forwarding the original email to the list as I had sent on= ly to Gabriel by accident)

Well, as= far collections go, you don't need "large libraries". You ju= st 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= 9;s gen
package, and gen itself is a single module that could, if there was the wil= l, 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 "sug= ar" and
what is essential infrastructure. You do not want to farm out infrastructur= e 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 ti= me
information, it would be acceptable to leave advanced time-handling mechani= cs to
specialized libraries outside of the stdlib, as long as they were able to r= ely
on a *lingua franca* of standard types.

Of course, all that wouldn't solve the design issues of the standard li= brary
(eg, Str, exceptions everywhere, etc.), but adding gen (or at least hooks f= or
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 c= ould
reach some kind of consensus.

Cheers,

Emm

--001a1149d300689469051e4f54fb--