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 1E5C27F0D9 for ; Thu, 27 Aug 2015 10:17:50 +0200 (CEST) IronPort-PHdr: 9a23:kEOx4hSNg95cOe54iDPT8eGUotpsv+yvbD5Q0YIujvd0So/mwa64bRCN2/xhgRfzUJnB7Loc0qyN4/umBzZLuM3Z+Fk5M7VyFDY9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3CwN5K6zPF5LIiIzvjqbpq8aVPV8D3WHlKZpJbzyI7izp/vEMhoVjLqtjgjDomVBvP9ps+GVzOFiIlAz97MrjtLRq8iBXpu5zv5UYCfayV+0CQLdZFDUrNXwurI2u7EGbDFjH2nxJe2MKkh1OEkD55Q/3WJrr+n/zsPZ93y+Le9H/U70yVC6K4KJiSRuugyACYW0X6mbS3+N5hrharRbpnBd/zpTZesnBO/N0ZKLQeZUBTmpMRMtLfyNEC4K4KYAICrxSbq5js4Dhqg5W/lOFDg62Cbaqk2cQiw== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-io0-f177.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.177 as permitted sender) identity=mailfrom; client-ip=209.85.223.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@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-io0-f177.google.com) identity=helo; client-ip=209.85.223.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-io0-f177.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CzAQAQx95Vm7HfVdFdhBsBPAaDHb8bgy4KAoEnBzsRAQEBAQEBAQEQAQEBAQEGCwsJIS6CHYIHAQEEEhEdARsdAQMMBgULDQICJgICIQEBEQEFARwGExQHB4d2AQMSpiCBLz4xi0CBbIJ5iiMKGScNVoRZAQsaAQUOgRSJPIEDgk+BUzYzB4JpgUMFlT2LBoFtgUqRW4NQgh8SI4EXF4QQPDOCTQEBAQ X-IPAS-Result: A0CzAQAQx95Vm7HfVdFdhBsBPAaDHb8bgy4KAoEnBzsRAQEBAQEBAQEQAQEBAQEGCwsJIS6CHYIHAQEEEhEdARsdAQMMBgULDQICJgICIQEBEQEFARwGExQHB4d2AQMSpiCBLz4xi0CBbIJ5iiMKGScNVoRZAQsaAQUOgRSJPIEDgk+BUzYzB4JpgUMFlT2LBoFtgUqRW4NQgh8SI4EXF4QQPDOCTQEBAQ X-IronPort-AV: E=Sophos;i="5.17,421,1437429600"; d="scan'208";a="175009821" Received: from mail-io0-f177.google.com ([209.85.223.177]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 27 Aug 2015 10:17:48 +0200 Received: by iods203 with SMTP id s203so48673386iod.0 for ; Thu, 27 Aug 2015 01:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CykNPNQhSki2CpzdTpoKLNNEe2fniW7jorUqoLYO60g=; b=jtvxGD9hhMH0k+5CeLevWD8SEDSHsViJbpSXMp56xdW3+F5E+8vO5zmP08CcG+Fcf/ SuoJklYxEfXoStjZPTSlzVbPwA0fFB8CmR42XzjpM9vHkDMzSJ+PS2MowRxvvdjf5Vkt G8DqHcMSBwK70Eb7R5PK0o3S0ye7VqyA/6kD9Jp+2t+rogDL0p3oAJt7qP2d/72+FeSo VY4TmUTHOoLpN+q7T/yVIoOdG8UrzZJkZr1c1+7Zzr4Zh65ODxFYXhkwhkkC99Q+DxcO 5+pI6M2Mp4VlqXcqORj0JTy96a1mjZz/NTUXN2R0nYmXLRuOuOw7EXVTsvmDOtKcSf4i 0XWA== X-Received: by 10.107.128.83 with SMTP id b80mr8611213iod.84.1440663467658; Thu, 27 Aug 2015 01:17:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.68.132 with HTTP; Thu, 27 Aug 2015 01:17:08 -0700 (PDT) In-Reply-To: References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> From: Gabriel Scherer Date: Thu, 27 Aug 2015 10:17:08 +0200 Message-ID: To: Anthony Tavener Cc: Hongbo Zhang , "caml-list@inria.fr" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really 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. (Small independent packages have their own issues ("cabal hell"), so maybe it's a case of seeing the greener pasture on the other side of the fence. I think that's at least worth trying.) On Thu, Aug 27, 2015 at 9:18 AM, Anthony Tavener wrote: > I tend to live-in and build my own ecosystem anyway, so I haven't used any > of these libraries. But I've looked at them... and I think "containers" g= oes > for a more self-contained-module approach like you were looking for with > string split... Looking at it now I see the 'sep' function does use a bit > from within the CCParse module it's defined in -- but that module is built > on the parser combinators it defines. I think the individual module can be > taken as-is, or parts of it, without hunting down other module dependenci= es. > > This doesn't address the core problem you raise. Haven't thought much abo= ut > it, as I'm one of the few(?) who is okay with the sparse standard library. > For games, it's pretty much tradition that you write your own stdlib anyw= ay > -- things end up being different... stressing particular use-cases or > performance characteristics. And, overall, not suitable for general > purposes. DBuenzli has contributed a lot which is actually quite > game-relevant, and his style is standalone modules. You could consider his > collection of "libraries" (modules really) as a library in it's own right. > :) Maybe that style is a good model? Come to think of it, the OCaml stdlib > modules are generally quite standalone, aside from Pervasives, aren't the= y? > So maybe ccube-containers and dbuenzli's style are really very OCaml-ish. > > My own stuff, by comparison, is horribly layered with dependencies. I > generated a dot-graph showing dependencies and nearly everything depends = on > another module, often which depend on others. I don't like redundant code, > and this is the result... but it makes for modules which cannot be easily > teased apart. Probably similar to Batteries-style. > > -Tony > > > On Wed, Aug 26, 2015 at 8:52 PM, Hongbo Zhang > 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 >> =E2=80=9CString.split=E2=80=9D which split a string into a list of strin= gs 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 s= ure >> 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=E2=80=99s time to write my o= wn 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=E2=80= =99t do >> anything. >> Note that I don=E2=80=99t want to be offensive to any of these libra= ries, 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=E2=80=99s big with dependencies between different modules (OCam= l 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 implementatio= n 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=E2=80=99s 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 pre= fer >> 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 =E2=80=94 Hongbo > >