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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id CCA487F0D9 for ; Thu, 27 Aug 2015 09:18:56 +0200 (CEST) IronPort-PHdr: 9a23:A1jPnR+SvUyFy/9uRHKM819IXTAuvvDOBiVQ1KB92+IcTK2v8tzYMVDF4r011RmSDd6dtagP0rOL+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuStWU0Z78jrnvs7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cYk7sb+sVBSaT3ebgjBfwdVWx+cjN92Mq+lR7FQgGIrkkcW2MZ2k5CBALX7Bj8Uc6g4nvSue902S3cNsrzG+MaQzOnuo5tVB/vjjZPCzcn/WfakIQkhaRHoBWntlpjypDZZoyPHPV7d6LZO9gdQDwSDY5qSyVdD9bkPMM0BO0bMLMd9tGlqg== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=anthony.tavener@gmail.com; spf=Pass smtp.mailfrom=anthony.tavener@gmail.com; spf=None smtp.helo=postmaster@mail-wi0-f174.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anthony.tavener@gmail.com) identity=pra; client-ip=209.85.212.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of anthony.tavener@gmail.com designates 209.85.212.174 as permitted sender) identity=mailfrom; client-ip=209.85.212.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f174.google.com) identity=helo; client-ip=209.85.212.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="postmaster@mail-wi0-f174.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CRAQCOuN5VlK7UVdFdhBsBLQ8Ggx2oPZIeh3MCgScHORMBAQEBAQEBARABAQEBBwsLCR8wgh2CBwEBAwESER0BGx0BAwELBgULAzQCAiEBAREBBQEcBhMUBweHdgEDCgimL4EvPjGLQIFsgnmKIwoZJw1XhFkBAQEBBgEBAQEBARYBBQ6KSoEDgk+BUmkHgmmBQwWNYYdbiwWBbYFKkVmDUIIfEiOBFxeELR8zgk0BAQE X-IPAS-Result: A0CRAQCOuN5VlK7UVdFdhBsBLQ8Ggx2oPZIeh3MCgScHORMBAQEBAQEBARABAQEBBwsLCR8wgh2CBwEBAwESER0BGx0BAwELBgULAzQCAiEBAREBBQEcBhMUBweHdgEDCgimL4EvPjGLQIFsgnmKIwoZJw1XhFkBAQEBBgEBAQEBARYBBQ6KSoEDgk+BUmkHgmmBQwWNYYdbiwWBbYFKkVmDUIIfEiOBFxeELR8zgk0BAQE X-IronPort-AV: E=Sophos;i="5.17,421,1437429600"; d="scan'208";a="143916850" Received: from mail-wi0-f174.google.com ([209.85.212.174]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 27 Aug 2015 09:18:55 +0200 Received: by widdq5 with SMTP id dq5so68395058wid.1 for ; Thu, 27 Aug 2015 00:18:55 -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 :cc:content-type; bh=Zco8rbcYrI5qpKxpOAalMf7iPe0ARIhprycUPP7rv3U=; b=RrboUS8zl8Aa3EJb4Mut4JsCwMsN+AQL6EHasniwpPGc/btEZpf9fFzuNg/O7UKmuj hmYd3NwSoMDPye4zcGS0wm1hR6OlIGOqXLmBWtc/7gXjzjd2xU5HcZI/YRSrM3Fghm7n SNNEDEBfuz0U+7M4oy+Fs9jpsuEYvx2Ovo+M9LrExWqCfWx2Hfa/Qfie2MvPiTNgjgHl /M57eFFHdYmtM5BENzV0gXI+h/qGLM8jUCG1+1SoyXFF+BDGmGBcokP9Tx/ihh4QCtEf zhVhfcAUXzEGWS08wB8Oj4QS/eWUa0iXQ57aJLJbyomQv9JA1tS7k30dPHs2dnX2n2en gHSA== MIME-Version: 1.0 X-Received: by 10.180.105.74 with SMTP id gk10mr9324681wib.92.1440659935516; Thu, 27 Aug 2015 00:18:55 -0700 (PDT) Received: by 10.28.93.4 with HTTP; Thu, 27 Aug 2015 00:18:55 -0700 (PDT) In-Reply-To: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> Date: Thu, 27 Aug 2015 01:18:55 -0600 Message-ID: From: Anthony Tavener To: Hongbo Zhang Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=f46d04426ca6b2dea2051e45c7a0 Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really --f46d04426ca6b2dea2051e45c7a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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" 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 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 dependencies. This doesn't address the core problem you raise. Haven't thought much about 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 anyway -- 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 they? 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 string= s by whitespace, > it is just one liner if you use str library. However, since I am doing so= me > 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 > 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 > 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=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 > problem as batteries, a big dependency. There is a blocking issue, its > development process is opaque, for an open source community, I would pref= er > 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 > --f46d04426ca6b2dea2051e45c7a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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" goes for a more self-contained-module appro= ach 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 dependencies.

This doe= sn't address the core problem you raise. Haven't thought much about= it, as I'm one of the few(?) who is okay with the sparse standard libr= ary. For games, it's pretty much tradition that you write your own stdl= ib anyway -- things end up being different... stressing particular use-case= s or performance characteristics. And, overall, not suitable for general pu= rposes. DBuenzli has contributed a lot which is actually quite game-relevan= t, and his style is standalone modules. You could consider his collection o= f "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 stdli= b modules are generally quite standalone, aside from Pervasives, aren't= they? So maybe ccube-containers and dbuenzli's style are really very O= Caml-ish.

My own stuff, by comparison, is horribly= layered with dependencies. I generated a dot-graph showing dependencies an= d 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 f= or modules which cannot be easily teased apart. Probably similar to Batteri= es-style.

-Tony


On Wed, Aug 26, 2015 at 8:52 PM, Hongbo Zha= ng <bobzhang1988@gmail.com> wrote:
Dear OCaml developers,<= div>=C2=A0 =C2=A0 I would like to spend one hour in writing down my experie= nce that why I had to write some small utilities again and again, since thi= s happened so many times that I believe you might come across such issues b= efore.
=C2=A0 =C2=A0 I am doing some compiler hacking tonight, I = needed a utility function =E2=80=9CString.split=E2=80=9D which split a stri= ng into a list of strings by whitespace, it is just one liner if you use st= r library. However, since I am doing some low level stuff, I would try to a= void such big dependency, and I am pretty sure that I have ever written it = =C2=A0for at least three times, I just hoped that I could get it done quick= ly, 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 pre= viously defined functions, then I copied the whole module `BatString` into = REPL, still no luck, it depended on another module `BatReturn`, then I stop= ped here, it=E2=80=99s time to write my own ad-hoc thrown-away `String.spli= t` function again.
=C2=A0 =C2=A0OCaml is my favorite programming = language, and I am very productive at it, however, I was annoyed by such th= ings from time to time. We do have four *standard libraries* alternatives: = batteries, core, extlib and ocaml-containers. In my opinion, none of them m= atches the beauty of the OCaml language itself and probably will never catc= h up if we don=E2=80=99t do anything.=C2=A0
=C2=A0 =C2=A0 Note th= at I don=E2=80=99t want to be offensive to any of these libraries, 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 mainta= ining these libraries, better than nothing : )
=C2=A0 =C2= =A0 - Batteries(extlib)
=C2=A0 =C2=A0 =C2=A0 It=E2=80=99s big wit= h dependencies between different modules (OCaml does not have a good story = in dead code elimination), some of its modules are of low quality, for exam= ple, batEnum is used everywhere while its implementation is buggy. batIO ma= kes things even worse since it is not compatible with standard library, som= e type signatures mismatched IIRC.
=C2=A0 =C2=A0 - ocaml-containe= rs
=C2=A0 =C2=A0 =C2=A0 Mostly one man=E2=80=99s project
=C2=A0 =C2=A0 - core
=C2=A0 =C2=A0 =C2=A0 I believe core has hi= gh quality, however, it suffers the same problem as batteries, a big depend= ency. There is a blocking issue, its development process is opaque, for an = open source community, I would prefer a standard library developed in an op= en environment.=C2=A0
=C2=A0 =C2=A0 I am not expecting that we co= uld have a =C2=A0standard library as rich as python, but for some utilities= , I do believe that shipped with standard library or officially supported i= s the best solution.
=C2=A0 =C2=A0Thanks =E2=80=94 Hongbo=C2=A0

--f46d04426ca6b2dea2051e45c7a0--