From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 9D9847F16D for ; Fri, 28 Aug 2015 02:49:45 +0200 (CEST) IronPort-PHdr: 9a23:d4dU9hKj+cCh9rnsrNmcpTZWNBhigK39O0sv0rFitYgUI/TxwZ3uMQTl6Ol3ixeRBMOAu6kC1bed7/qocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC1ILpiqvuodX6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPHs4FPMRAGV53YYFH4dkhdSDhLt4xTzX5O3uSz//KIp1yCQJ8z7SfYvUjSv9apxYBDtgSYDcTU+9TeEpNZ3ifd7pxSurRs38Y7dZo7dYPB5dLHddNUVHDsRDu5eUiVABsW3aI5ZXLlJBvpRs4So/whGlhC5HwT5Qbq3kjI= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=bobzhang1988@gmail.com; spf=Pass smtp.mailfrom=bobzhang1988@gmail.com; spf=None smtp.helo=postmaster@mail-qg0-f45.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of bobzhang1988@gmail.com) identity=pra; client-ip=209.85.192.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="bobzhang1988@gmail.com"; x-sender="bobzhang1988@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of bobzhang1988@gmail.com designates 209.85.192.45 as permitted sender) identity=mailfrom; client-ip=209.85.192.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="bobzhang1988@gmail.com"; x-sender="bobzhang1988@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-qg0-f45.google.com) identity=helo; client-ip=209.85.192.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="bobzhang1988@gmail.com"; x-sender="postmaster@mail-qg0-f45.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DPAQDurt9Vmy3AVdFehBsBPMJAgzgCgT88EAEBAQEBAQEBEAEBAQEBBgsLCSEjC4IdggcBAQQSER0BGx0BAwwGBQsNAgImAgIhAhEBBQEcBhMUBweHdgEDEgWjVIEvPjGLQIFsgnmKGwoZJw1WhEcBAQEBAQEBAwEBAQEBAQEBARMBBQ6BFIdWgWaBA4JPgVM2MweCaS+BFAWVNgeLBoFtgUqHHg+KL4NQgh81gRcXhCpVgk0BAQE X-IPAS-Result: A0DPAQDurt9Vmy3AVdFehBsBPMJAgzgCgT88EAEBAQEBAQEBEAEBAQEBBgsLCSEjC4IdggcBAQQSER0BGx0BAwwGBQsNAgImAgIhAhEBBQEcBhMUBweHdgEDEgWjVIEvPjGLQIFsgnmKGwoZJw1WhEcBAQEBAQEBAwEBAQEBAQEBARMBBQ6BFIdWgWaBA4JPgVM2MweCaS+BFAWVNgeLBoFtgUqHHg+KL4NQgh81gRcXhCpVgk0BAQE X-IronPort-AV: E=Sophos;i="5.17,423,1437429600"; d="scan'208";a="175122645" Received: from mail-qg0-f45.google.com ([209.85.192.45]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 28 Aug 2015 02:49:44 +0200 Received: by qgdu11 with SMTP id u11so6588822qgd.1 for ; Thu, 27 Aug 2015 17:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MyXn9k0CL7lEgHb5hCKN6Adng5r1zoYFoKabFGkSFn0=; b=tNaEuvqGCrmVYbUTNn+weV/P88wz7TgXqtjBu5xhnlmlQYJj5D/AVUb0p1kk8l0n/Y MR+9orYWecJ9eVVC5l9bj1RmBLNY16BDlyw0VaUGy2whTuUsXWaJfAJ29AJYVKoCwbkE T2UTRFjZqc1Bpr3VYE1LNph34wvbY0ck880Vtlc6hfQwA2cSSa35F12JlUyc1bHKNL8A 02CWIEuo3LiRftiNJmDfPaNNAjtrJCWAtqSNcfqwObl0m8oIVGuMNDjxcJnthvbtO12J wRzqv+JOh4T8yVXnbViUI+SNWrBiAXqCbSO3QjlUke+l1uCoDvicSyZdAbebClCEHhnB 3DOA== X-Received: by 10.140.235.143 with SMTP id g137mr11980446qhc.102.1440722982817; Thu, 27 Aug 2015 17:49:42 -0700 (PDT) Received: from [192.168.5.10] (ip-64-134-70-81.public.wayport.net. [64.134.70.81]) by smtp.gmail.com with ESMTPSA id e19sm2285433qhc.18.2015.08.27.17.49.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Aug 2015 17:49:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Hongbo Zhang In-Reply-To: Date: Thu, 27 Aug 2015 20:50:49 -0400 Cc: Anthony Tavener , "caml-list@inria.fr" Content-Transfer-Encoding: quoted-printable Message-Id: <232BE7C3-99C1-44DF-B6D4-C5C19355C098@gmail.com> References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> To: "gabriel.scherer@gmail.com" X-Mailer: Apple Mail (2.2098) Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really Hi Gabriel, To answer your questions in particular, standard library should not be c= onsidered a dependency, since for people who use your library, there is no = cost. Yes, I agree that it would be even better when enriching the standard= library, we would try to make it self contained. When I was at school, I can play with OPAM, and install any dependency i= f I like(thanks to OPAM), however, in the industry setting, esepcially a bi= g company which takes IP in a serious way, it is damn hard to introduce a t= hird party library, the time spent in convincing your legal department is m= ore than you roll your own version. Thanks -- Hongbo > On Aug 27, 2015, at 4:17 AM, Gabriel Scherer = wrote: >=20 > 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 >=20 > 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? >=20 > 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. >=20 > (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.) >=20 > 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. >=20 >=20 > 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. >=20 > =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. >=20 > 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). >=20 > 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. >=20 > (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.) >=20 > 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 a= ny >> of these libraries. But I've looked at them... and I think "containers" = goes >> 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 bui= lt >> 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 dependenc= ies. >>=20 >> This doesn't address the core problem you raise. Haven't thought much ab= out >> it, as I'm one of the few(?) who is okay with the sparse standard librar= y. >> For games, it's pretty much tradition that you write your own stdlib any= way >> -- 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 h= is >> collection of "libraries" (modules really) as a library in it's own righ= t. >> :) Maybe that style is a good model? Come to think of it, the OCaml stdl= ib >> modules are generally quite standalone, aside from Pervasives, aren't th= ey? >> So maybe ccube-containers and dbuenzli's style are really very OCaml-ish. >>=20 >> 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 cod= e, >> and this is the result... but it makes for modules which cannot be easily >> teased apart. Probably similar to Batteries-style. >>=20 >> -Tony >>=20 >>=20 >> On Wed, Aug 26, 2015 at 8:52 PM, Hongbo Zhang >> wrote: >>>=20 >>> 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 happene= d 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 stri= ngs by whitespace, it >>> is just one liner if you use str library. However, since I am doing som= e low >>> level stuff, I would try to avoid such big dependency, and I am pretty = sure >>> that I have ever written it for at least three times, I just hoped tha= t 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 batterie= s, >>> batteries is too big for my projects. `BatString.nsplit` seems to fit f= or >>> 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 anoth= er >>> module `BatReturn`, then I stopped here, it=E2=80=99s time to write my = own 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 implementati= on 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 pr= efer >>> 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 >>=20 >>=20