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 AABD97FE36 for ; Fri, 1 Jul 2016 14:46:32 +0200 (CEST) IronPort-PHdr: 9a23:g07evBCnb4kEaHJe6NT3UyQJP3N1i/DPJgcQr6AfoPdwSP7yr8bcNUDSrc9gkEXOFd2CrakV06yP4uu9ASQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd+KyZ3mnL3qs7ToICxwzAKnZr1zKBjk5S7wjeIxxbVYF6Aq1xHSqWFJcekFjUlhJFaUggqurpzopM0r221qtvkg789NV7nhN+R9FOQATWcQCH0u/MDgqTXESAKO4DNcDjRXwVJ0BF3p4Rj8FqvxtS7ire17kH2WMMTwVrA5Qyii6KJzUxjuoCgCPj89tmrQj5ojorhcpUeQrgZ4xcbxYYeON+s2KrLYfNUBRntpXM9XWjddGI6xc80ECO9XbrUQlJX0u1Zb9Uj2PgKrHu66j2IRiw== 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: A0BzAADqZHZXfeXIaSZdhBR8BqgdhR2OCyKFdgKBMgc8EAEBAQEBAQEBEQEBCRYJUIIyghsBBRIRHQEBLAsBDwsLDQICCR0CAiEBEgEFAQoSBhMSAgcHh3QDFwMLpiiBMT4xilRnhEMBAQWHKQMKhBsBAQEBAQEEAQEBAQEBAQEBFggQcYUnhE2CQ4FjGoMBglqGVQyHJYpbNIYJhi6CDYI4jHKIFoY0Eh6BDzWCJxyBaFKIdAEBAQ X-IPAS-Result: A0BzAADqZHZXfeXIaSZdhBR8BqgdhR2OCyKFdgKBMgc8EAEBAQEBAQEBEQEBCRYJUIIyghsBBRIRHQEBLAsBDwsLDQICCR0CAiEBEgEFAQoSBhMSAgcHh3QDFwMLpiiBMT4xilRnhEMBAQWHKQMKhBsBAQEBAQEEAQEBAQEBAQEBFggQcYUnhE2CQ4FjGoMBglqGVQyHJYpbNIYJhi6CDYI4jHKIFoY0Eh6BDzWCJxyBaFKIdAEBAQ X-IronPort-AV: E=Sophos;i="5.26,557,1459807200"; d="scan'208";a="183472891" 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; 01 Jul 2016 14:46:31 +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 1bIxq2-00073P-2A for caml-list@inria.fr; Fri, 01 Jul 2016 08:46:30 -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 BXdmYg-AAACJj-VS; 2016-07-01 08:46:24.682276-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 1bIxpw-0005kU-J3 for caml-list@inria.fr; Fri, 01 Jul 2016 08:46:24 -0400 Received: by mail-qk0-f198.google.com with SMTP id e3so153334220qkd.2 for ; Fri, 01 Jul 2016 05:46:24 -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-transfer-encoding; bh=ufWZ09pDeFYw3DH53XsUo5FGPCihSI7X8Cj05uWPhVY=; b=VVUV2FmT0YL6xlcoWvGe9Y3Qe61WgMHZ9Zy+q6Kb4+6moKuPs0v0mwSJBvViXAqgl1 OLI72klo7s2B9gZCt6J7XnHIvO2WS5CaceITDrTrjASP98l/92QxOBFr1bmJMOCVymmT rqik0VJzhBjOPTGClsCZ7sXPwFOe7/cf3br5w= 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-transfer-encoding; bh=ufWZ09pDeFYw3DH53XsUo5FGPCihSI7X8Cj05uWPhVY=; b=aqofVUW0Davyu6Ex3ENS7ZxABxW9g6YqYRDD/OXf1xNG/aNgJsfeSm2zsSulzmFAGR Gke2Idk+Gb+rS5W7g33iv9EZabKRzxKGAHKWIS13N+LaRTGVBsSgZTaeVEnqZbBrrl// 6chjT/z0GHdKPxR4hPOJxwFsD9aE+Eg8wAHKu2IN3BSs4ybUJ60TSSM0i+KX0GrE+UBx b/z5Ma3u63XGNE3KBE6M8XMYlpcS/Ihi9avnylAIOQTfEw2SA8xe+jo4Kj3t+IpPufRv u/Ky5RcAjQ449kllvH9MFu8pldNxLjbT9T1xzZtgL8vXUl6kbIEe+/uSggDVRyGOBeBn qUzA== X-Gm-Message-State: ALyK8tL9EnDVaU5fvoKXd3ihmj/WnCa9bKAlU+yhUZeIXfkmBEdiAkQs+cRMQBxSikqRLcdcmBIv5S4wxLrBxpAbvNNwsiS+An8Uh0bJ9NvMA5EGSg+9QDBSkbsQ2Dc7oJkSkMnFqlhOOwR6GvGwN+2sesDcOjVu/F+nPeKeReY= X-Received: by 10.13.254.130 with SMTP id o124mr9232077ywf.30.1467377184223; Fri, 01 Jul 2016 05:46:24 -0700 (PDT) X-Received: by 10.13.254.130 with SMTP id o124mr9232066ywf.30.1467377183998; Fri, 01 Jul 2016 05:46:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.200 with HTTP; Fri, 1 Jul 2016 05:46:23 -0700 (PDT) In-Reply-To: <6FB9D602-BBED-4175-B230-0F181DB61824@gmail.com> References: <7785E51D-EC74-4A78-8840-D4A7C18E3C56@gmail.com> <6FB9D602-BBED-4175-B230-0F181DB61824@gmail.com> From:Yaron Minsky Date: Fri, 1 Jul 2016 08:46:23 -0400 Message-ID: To:Dean Thompson Cc:Ivan Gotovchits , caml-list , Jeremy Yallop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-JS-Processed-by: mailcore Subject: Re: [Caml-list] how to encourage adoption of OCaml? Jeremie (who is currently on vacation) could probably say more about the technical merits. I mostly think it's good enough, except for the fact that the executable size is portable, and Async hasn't yet gotten support for running on Windows (although it does run fine on Javascript.) I think if those things are done, and Lwt users were eager to use it, I suspect it would be pretty close to workable. y On Fri, Jul 1, 2016 at 8:44 AM, Dean Thompson wrote: > Yaron, since you describe janestreet/lwt-async as "an experiment in this = direction=E2=80=9D, could you give a quick overview of how a practical lwt-= async would compare with what was done there? > > Dean > >> On Jun 30, 2016, at 8:13 PM, Yaron Minsky wrote: >> >> I'm not at all sure that the decoupling is possible or wise for Async. >> My intuition is that this is too complex of a problem with too much >> need for careful optimization to be able to have a simple, shared >> generic data structure for this. >> >> The solution that seems most plausible to me is to settle on one >> implementation, and port the API of one library to run on top of the >> other. There was indeed an experiment in this direction that was done >> by Jeremie Dimino: >> >> https://github.com/janestreet/lwt-async >> >> That said, until we resolve the binary size issues with Core and >> therefore Async, I doubt that this solution would be appealing to the >> full community of lwt users. >> >> y >> >> On Thu, Jun 30, 2016 at 9:13 AM, Ivan Gotovchits wrote: >>> >>> >>> On Thu, Jun 30, 2016 at 8:12 AM, Yaron Minsky >>> wrote: >>>> >>>> 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 stan= dard >>>> interchange types (array, string, option, list, char, and now result) = that >>>> are provided by the stdlib, so whether you use Core (or Core_kernel) b= ecomes >>>> more a matter of personal preference, and shouldn't hinder interoperab= ility. >>>> >>>> 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 functional= ity, >>>> and mixing and matching between two schedulers is not so easy. I'd lov= e to >>>> see some resolution here, but it's not clear what the solution would b= e. >>> >>> The solution would be to use the same approach as with standard types. = We >>> need a common base inductive type for `Lwt.t` (aka `Ivar.t`), which will >>> represent a value which is defined in some point in the future (hence a >>> `future` is a good name). Another type is for capturing a concept of a >>> variable that can have multiple values in the future, that is represent= ed as >>> `Lwt_stream.t` or `Pipe`. Currently in both Lwt and Async the main thre= ad >>> type is tightly coupled with the underlying implementation, especially = in >>> Async (Lwt.t can be easily decoupled). >>>> >>>> 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 OC= aml, >>>>> 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 appea= rs >>>>>>> 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 a= nd >>>>>> 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 f= ew >>>>>> 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 typ= es >>>>>> 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 >>> >>> >