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 17AC57F16D for ; Thu, 27 Aug 2015 16:17:57 +0200 (CEST) IronPort-PHdr: 9a23:lmnn9xwcOxiF7zXXCy+O+j09IxM/srCxBDY+r6Qd0eIWIJqq85mqBkHD//Il1AaPBtWArawYwLWO+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuStWU0Zj8iLj60qaQSjsLrQL1Wal1IhSyoFeZnegtqqwmFJwMzADUqGBDYeVcyDAgD1uSmxHh+pX4p8Y7oGx48sgs/M9YUKj8Y79wDfkBVGxnYCgJ45jLsh/MRwzH1HsVVGpexhBPCRrF5Rf1B8ah4gP1s+N83G+ROsigHp4uXjH33q5xTxmgrSYBLD0ouDXGj812l6FKiBCooRFk35TZbZ3TP/17KPCONegGTHZMC54CHxdKBZmxOs5WV7IM Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=yminsky@janestreet.com; spf=Pass smtp.mailfrom=yminsky@janestreet.com; spf=None smtp.helo=postmaster@mxout4.mail.janestreet.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.233; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.233 as permitted sender) identity=mailfrom; client-ip=38.105.200.233; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.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@mxout4.mail.janestreet.com) identity=helo; client-ip=38.105.200.233; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@mxout4.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CWAQCsG99VnOnIaSZdhBsBPAaDHcJRAoEoBzwQAQEBAQEBAQEQAQEBAQEGFglPgh2CBwEBBBIRHQEBLAsBDwsLAwoCAiYCAiEBEgEFARwGExQHB4d3AxIDpU+BLz4xik9xhGUBBYpsDYUvAQEBAQEFAQEBAQEBARUGCoEYiTyBA4JPgVM2MweCaYFDjWaHXIsGgW2TJYVvEiOBFxeCHhyBc1KCTQEBAQ X-IPAS-Result: A0CWAQCsG99VnOnIaSZdhBsBPAaDHcJRAoEoBzwQAQEBAQEBAQEQAQEBAQEGFglPgh2CBwEBBBIRHQEBLAsBDwsLAwoCAiYCAiEBEgEFARwGExQHB4d3AxIDpU+BLz4xik9xhGUBBYpsDYUvAQEBAQEFAQEBAQEBARUGCoEYiTyBA4JPgVM2MweCaYFDjWaHXIsGgW2TJYVvEiOBFxeCHhyBc1KCTQEBAQ X-IronPort-AV: E=Sophos;i="5.17,422,1437429600"; d="scan'208";a="175075485" Received: from mxout4.mail.janestreet.com ([38.105.200.233]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2015 16:17:55 +0200 Received: from tot-qpr-mailcore2.delacy.com ([172.27.56.106] helo=tot-qpr-mailcore2) by mxout4.mail.janestreet.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1ZUy02-0003z7-9a for caml-list@inria.fr; Thu, 27 Aug 2015 10:17:54 -0400 X-JS-Flow: external Received: by tot-qpr-mailcore2 with JS-mailcore (0.1) (envelope-from ) id BV3xwS-AAAG6d-IH; 2015-08-27 10:17:54.260734-04:00 Received: from mail-io0-f181.google.com ([209.85.223.181]) by mxgoog1.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1ZUy02-0008Dx-6D for caml-list@inria.fr; Thu, 27 Aug 2015 10:17:54 -0400 Received: by iodb91 with SMTP id b91so58240307iod.1 for ; Thu, 27 Aug 2015 07:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=AHMO3H5Cl6ux7APajoJ5WgrmDOiaZNCU/fHInXFJ1Y0=; b=wCRb5JIBwYf+cXf7u8kXZfOlHoIOuxiEepHCQd3a4/W9MYXXyPPiDJ5hWZ2IkSEfBq k0sGrjrbWC2b7zYZesNPpawuCWclyufsENkQfPgq1TbgylsHKhD6PhI9WF43UTe+MiMx KYlT46DsmGi4WJfAGON1KkBittxBWo41IlPTw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=AHMO3H5Cl6ux7APajoJ5WgrmDOiaZNCU/fHInXFJ1Y0=; b=FiQg4yVZNMCqrERfn8GuKZCtel4nxsLab+M6pzSYNZWudi5sxYSqxEom2dgXk3S6xi XBT2VWig9OCi2Q9XOLM2UC7ikL0NULkvGA4Io7stRXT56ne7LjWnPCSM8F4ZCezgHGgA wZOrtZX90L6CxX7rVGj24c27DTTkCn+3XJ4VhOytIPQqV73Ad/kfQkvh6XapGauhQlsF wre8nXvgtJckHec3gjdDSYAYFFE6SMwZB3p4NYDHK8KroBlUvsMM86yGGb90UwPtMoJn MGLYQPJ3p0dU7KEc7T57UO2dibaoIixGdlLJDaAcXwBHLC13Rp9bi5ULEMxSAp33och7 EL+g== X-Gm-Message-State: ALoCoQnX/zX0PB0WsIpJ7gtbrd/wWRqAnyW58V1aj03rqbbih5kZW89tBg4bYJU4lFgmmyh3q8EVkVgoXrrrT8HxA2b2uXy5HOTRLXdUzCX17CvVy6eDs6ikCWQhZE6aFDTT3COVagIA X-Received: by 10.107.151.194 with SMTP id z185mr9889241iod.63.1440685073853; Thu, 27 Aug 2015 07:17:53 -0700 (PDT) X-Received: by 10.107.151.194 with SMTP id z185mr9889217iod.63.1440685073603; Thu, 27 Aug 2015 07:17:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.65.218 with HTTP; Thu, 27 Aug 2015 07:17:34 -0700 (PDT) In-Reply-To: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> From:Yaron Minsky Date: Thu, 27 Aug 2015 08:17:34 -0600 Message-ID: To:Hongbo Zhang Cc:"caml-list@inria.fr" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-JS-Processed-by: mailcore Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really The core OCaml team is small, and having them focused on building a great compiler rather than on building a rich stdlib seems right to me. The improvements in packaging I think make the question of whether it's distributed with the compiler mostly a moot issue, I think. On the topic of Core: The issue of binary size is real. It will get somewhat better when we drop packed modules from the public release, which should come in the next few months (support for it internally is mostly in place.) That said the module-level dependency tracking is by its nature coarse, so binaries using Core (or the more portable Core_kernel) are still going to be relatively large. That said, I think I'd rather have the compiler folk work on improving dead-code elimination than integrating and maintaining a standard library. As to openness: we publish all changes on github, have a mailing list, and will accept pull requests; but it's true that the development of Core is focused within Jane Street, and that is unlikely to change. y On Wed, Aug 26, 2015 at 8:52 PM, Hongbo Zhang wrot= e: > 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 string= s 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 su= re > 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 ow= n 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 f= our > *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=99= t do > anything. > Note that I don=E2=80=99t want to be offensive to any of these librar= ies, 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 (OCaml= does not > have a good story in dead code elimination), some of its modules are of l= ow > quality, for example, batEnum is used everywhere while its implementation= 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 probl= em > as batteries, a big dependency. There is a blocking issue, its development > process is opaque, for an open source community, I would prefer 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