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 216137FE36 for ; Thu, 30 Jun 2016 14:12:42 +0200 (CEST) IronPort-PHdr: 9a23:y67npBbLAPZGYMjq3Jwdr97/LSx+4OfEezUN459isYplN5qZpcWybnLW6fgltlLVR4KTs6sC0LuO9fm/EjBRqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ3pzxjr/5p8ybSj4LrQL1Wal1IhSyoFeZnegtqqwmFJwMzADUqGBDYeVcyDAgD1uSmxHh+pX4p8Y7oGx48sgs/M9YUKj8Y79wDfkBVGxnYFYO+dbzuBLfYQyK73oaGiVKw1sbSzTCuT33V5G5jiv9s/Jm3y/SacH7RLYvWTm486dsTQfzjyEvODsw8WWRgct12vF1uhWk8i122YnSKKSUMuF9b+uJbNYbQ3FCT+5TXipMGZ+mYoYTSeEGOLAL/MHGu1ISoE7mVkGXD+T1x2oN2yb7 Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=yminsky@janestreet.com; spf=Pass smtp.mailfrom=yminsky@janestreet.com; spf=None smtp.helo=postmaster@mxout3.mail.janestreet.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mxout3.mail.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@mxout3.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DBAADrC3VXfeXIaSZahBR9BqgPhR2MEIF8IoV1AoEzBzoSAQEBAQEBAQERAQEJFglQgjKCGgEBAQMBEhEdAQEsCwEECwsLDQ0dAgIhARIBBQEKEgYTCAoJB4d0Aw8IAwulDoExPjGKVGeEQwEBBYcqAwqEHAEBAQEBAQEBAQEBAQEBAQEBAQEBARQIEIYYhE2CQ4FjR4JUglqGVQyRezSGCIYugguCOIxyiBOGMxIegQ8PFgaCJA0cgWhSiUgBAQE X-IPAS-Result: A0DBAADrC3VXfeXIaSZahBR9BqgPhR2MEIF8IoV1AoEzBzoSAQEBAQEBAQERAQEJFglQgjKCGgEBAQMBEhEdAQEsCwEECwsLDQ0dAgIhARIBBQEKEgYTCAoJB4d0Aw8IAwulDoExPjGKVGeEQwEBBYcqAwqEHAEBAQEBAQEBAQEBAQEBAQEBAQEBARQIEIYYhE2CQ4FjR4JUglqGVQyRezSGCIYugguCOIxyiBOGMxIegQ8PFgaCJA0cgWhSiUgBAQE X-IronPort-AV: E=Sophos;i="5.26,552,1459807200"; d="scan'208,217";a="183318602" Received: from mxout3.mail.janestreet.com ([38.105.200.229]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jun 2016 14:12:30 +0200 Received: from tot-qpr-mailcore2.delacy.com ([172.27.56.106] helo=tot-qpr-mailcore2) by mxout3.mail.janestreet.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1bIapZ-0001X3-O7 for caml-list@inria.fr; Thu, 30 Jun 2016 08:12:29 -0400 X-JS-Flow: external X-JS-Scanner-attachment: (warning) Scanner not connected Received: by tot-qpr-mailcore2 with JS-mailcore (0.1) (envelope-from ) id BXdQyt-AAABfq-WI; 2016-06-30 08:12:29.709339-04:00 Received: from mail-qk0-f198.google.com ([209.85.220.198]) by mxgoog1.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1bIapZ-00083b-Kb for caml-list@inria.fr; Thu, 30 Jun 2016 08:12:29 -0400 Received: by mail-qk0-f198.google.com with SMTP id e3so73604506qkd.2 for ; Thu, 30 Jun 2016 05:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=dcukxmM2RP6wq2QGOJKiztTdih+XxQJ7RlAhjHk2B0E=; b=0vI5buSJrfC+ZMe6GUW+QT1Gwxs839xRSdLU1fJ3n+GwXF6RkbvSd4w/oOxpJQEnjK EMf0e16sdzvaSHIh6ygID20LdQ5edqcbkJrrwO7C+ofYZQNHSISHDDwXHFPw0C1UxJ10 Cgb5OY+/VmocHff2mtsclKMtoEW+ubAitPL5s= 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:date :message-id:subject:from:to:cc; bh=dcukxmM2RP6wq2QGOJKiztTdih+XxQJ7RlAhjHk2B0E=; b=RM/OK86jk2pq+RUChMR4AJQha3XdSy4hUU50PraoHulk6JOsrfsnno8u2uXBY7MviK qAj8oWP0b0ILx9cl3drCvsR/A5JSq5rfKH5kHYurEf27mIpdL0GWyJT2OlF6TAWk7dkA xYhqrE1Ty6wOMx5APgRN7tW5TxBr8GkYOE9rwV4Px19hm+Oo6UllzQoj5BDGe6K8ytfa dvYBYxyJgDio0Sa/dyYv1JLJj83giy8UlgwLhucDVfLe59BPLWrrq0HGKE8tgDmI6K9Q 0FNrTraNM22D7XpImU6D3Tuv7sUFeg9HBxreWPWIsobdeSSBOHNo+PeW+fgaqhrpFWIf q4yg== X-Gm-Message-State: ALyK8tIEwBT1+OsFr3CD4aSTh5/WwRRdK1C1sDmJ7lQPyVX+JGBAAkJijxur/WVwavbWK+yvOY1mcohjWikoF9fisW478H+fnmB7OaUq4fO9aOPEz+nGR7YQoKoOEhXd/GknhYD/u6nSNXf3QYhzUZccbGsUOwAGwI9jWpb/K0w= X-Received: by 10.37.214.211 with SMTP id n202mr5806139ybg.124.1467288749338; Thu, 30 Jun 2016 05:12:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.37.214.211 with SMTP id n202mr5806120ybg.124.1467288749112; Thu, 30 Jun 2016 05:12:29 -0700 (PDT) Received: by 10.37.52.200 with HTTP; Thu, 30 Jun 2016 05:12:28 -0700 (PDT) Received: by 10.37.52.200 with HTTP; Thu, 30 Jun 2016 05:12:28 -0700 (PDT) In-Reply-To: <7785E51D-EC74-4A78-8840-D4A7C18E3C56@gmail.com> References: <7785E51D-EC74-4A78-8840-D4A7C18E3C56@gmail.com> Date: Thu, 30 Jun 2016 08:12:28 -0400 Message-ID: From:Yaron Minsky To:Dean Thompson Cc:caml-list@inria.fr, Jeremy Yallop Content-Type: multipart/alternative; boundary=94eb2c03bb0ead207505367dc82e X-JS-Processed-by: mailcore Subject: Re: [Caml-list] how to encourage adoption of OCaml? --94eb2c03bb0ead207505367dc82e Content-Type: text/plain; charset=UTF-8 A few thoughts: As Anil said, we're working on an updated RWO, which should resolve the camlp4 issue. As for mixing and matching between libraries that do and don't depend on Core, there's actually little difficulty here. Core sticks to the standard interchange types (array, string, option, list, char, and now result) that are provided by the stdlib, so whether you use Core (or Core_kernel) becomes more a matter of personal preference, and shouldn't hinder interoperability. One remaining problem with Core is the minimal executable size, which is currently much bigger if you use Core. We're considering some work in three next few months to make this much better. Async and Lwt are a real problem. They provide very similar functionality, and mixing and matching between two schedulers is not so easy. I'd love to see some resolution here, but it's not clear what the solution would be. Perhaps once we resolve the executable size issues of Core, there will be more appetite for some kind of merger of the two libraries. In the meantime, we're highly committed to continuing development and support for Async. y On Jun 30, 2016 6:32 AM, "Dean Thompson" wrote: > From my understanding so far, it seems to me that mixing and matching Core > and not-Core would be tough? Everything from result types to Lwt vs Async? > Given the inspirational and educational power of Real World OCaml, many > newcomers will face this issue. > > Dean > > > > On Jun 30, 2016, at 6:17 AM, Jeremy Yallop wrote: > > > >> On 30 June 2016 at 11:01, Dean Thompson > wrote: > >> It is hard for me to judge because I came through RWO, but it appears > to me that the lack of consensus on standard library comes up pretty > quickly. > > > > I think the standard library situation is much less of a concern than > > it once was, now that it's easy to distribute small OCaml packages and > > manage dependencies. > > > > In the past distribution difficulties discouraged dependencies: for > > example, even though many people prefer the design of ocaml-re and > > ocaml-pcre to the regular expression facilities in the standard > > library, the administrative overhead of an additional dependency made > > the standard library the easier choice overall. In that situation > > it's desirable for the standard library to be large and featureful. > > Nowadays there's much less benefit to having regular expression > > support in the standard library, since depending on ocaml-re or > > ocaml-pcre is just a matter of adding a line to an opam file and a few > > lines to the build configuration. > > > > The standard library still has a useful role to play, since it's > > easier to make libraries interoperate if they can communicate via > > common types, and several recent and proposed changes have that kind > > of role in mind. For example, the latest release of OCaml added a > > 'result' type to the standard library, which was previously defined in > > incompatible but essentially equivalent ways in several libraries: > > > > https://github.com/ocaml/ocaml/pull/147 > > > > and there's a proposal for adding iterators to various container types > > for the next release currently under discussion: > > > > https://github.com/ocaml/ocaml/pull/635 > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs --94eb2c03bb0ead207505367dc82e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A few thoughts:

As Anil said, we're working on an updated RWO, which sho= uld resolve the camlp4 issue.

As for mixing and matching between libraries that do and don= 't depend on Core, there's actually little difficulty here. Core st= icks to the standard interchange types (array, string, option, list, char, = and now result) that are provided by the stdlib, so whether you use Core (o= r Core_kernel) becomes more a matter of personal preference, and shouldn= 9;t hinder interoperability.

One remaining problem with Core is the minimal executable si= ze, which is currently much bigger if you use Core. We're considering s= ome work in three next few months to make this much better.

Async and Lwt are a real problem. They provide very similar = functionality, and mixing and matching between two schedulers is not so eas= y. I'd love to see some resolution here, but it's not clear what th= e solution would be. Perhaps once we resolve the executable size issues of = Core, there will be more appetite for some kind of merger of the two librar= ies.=C2=A0 In the meantime, we're highly committed to continuing develo= pment and support for Async.

y

On Jun 30, 2016 6:32 AM, "Dean Thompson&quo= t; <deansherthompson@gmail= .com> wrote:
= >From my understanding so far, it seems to me that mixing and matching Core = and not-Core would be tough? Everything from result types to Lwt vs Async? = Given the inspirational and educational power of Real World OCaml, many new= comers will face this issue.

Dean


> On Jun 30, 2016, at 6:17 AM, Jeremy Yallop <yallop@gmail.com> wrote:
>
>> On 30 June 2016 at 11:01, Dean Thompson <deansherthompson@gmail.com> wrote:
>> It is hard for me to judge because I came through RWO, but it appe= ars to me that the lack of consensus on standard library comes up pretty qu= ickly.
>
> I think the standard library situation is much less of a concern than<= br> > it once was, now that it's easy to distribute small OCaml packages= and
> manage dependencies.
>
> In the past distribution difficulties discouraged dependencies: for
> example, even though many people prefer the design of ocaml-re and
> ocaml-pcre to the regular expression facilities in the standard
> library, the administrative overhead of an additional dependency made<= br> > the standard library the easier choice overall.=C2=A0 In that situatio= n
> it's desirable for the standard library to be large and featureful= .
> Nowadays there's much less benefit to having regular expression
> support in the standard library, since depending on ocaml-re or
> ocaml-pcre is just a matter of adding a line to an opam file and a few=
> lines to the build configuration.
>
> The standard library still has a useful role to play, since it's > easier to make libraries interoperate if they can communicate via
> common types, and several recent and proposed changes have that kind > of role in mind.=C2=A0 For example, the latest release of OCaml added = a
> 'result' type to the standard library, which was previously de= fined in
> incompatible but essentially equivalent ways in several libraries:
>
>=C2=A0 =C2=A0https://github.com/ocaml/ocaml/pull/147<= br> >
> and there's a proposal for adding iterators to various container t= ypes
> for the next release currently under discussion:
>
>=C2=A0 =C2=A0https://github.com/ocaml/ocaml/pull/635<= br>
--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocam= l_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
--94eb2c03bb0ead207505367dc82e--