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 7C41C7FE36 for ; Thu, 30 Jun 2016 15:13:44 +0200 (CEST) IronPort-PHdr: 9a23:bbJkURA6lPO11fR8ypreUyQJP3N1i/DPJgcQr6AfoPdwSP7zocbcNUDSrc9gkEXOFd2CrakV06yP7Ou8CCQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd+KyZ3onLzjs7ToICxwzAKnZr1zKBjk5S7wjeIxxbVYF6Aq1xHSqWFJcekFjUlhJFaUggqurpzopM0r221qtvkg789NV7nhN+R9FOQATWcQCH0u/MDgqTXESAKO4DNcDjRXwVJ0BF305Qv9WN/Usy3htfs1jDifPMvtTqEcWz2k4rx3UhLllGEMMDtvo0/NjcklrbxSplqOoAB43YXUYZ2OfK5/YKz1fN4XSCxGRMkHBH8JOZ+1c4ZaV7lJBu1ftYSo4gZXoA== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=ivg@ieee.org; spf=Pass smtp.mailfrom=ivg@ieee.org; spf=None smtp.helo=postmaster@mail-lf0-f47.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of ivg@ieee.org) identity=pra; client-ip=209.85.215.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of ivg@ieee.org designates 209.85.215.47 as permitted sender) identity=mailfrom; client-ip=209.85.215.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; 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-lf0-f47.google.com) identity=helo; client-ip=209.85.215.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="postmaster@mail-lf0-f47.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DBAAC9GnVXhi/XVdFbhBR9BqgRhR2HD4Z9IoV1AoE0BzwQAQEBAQEBAQERAQEBCAsLCSEvgjKCGgEBAQMBEhEdAQEsCwEECwsLAwoNHQICIQESAQUBChIGEwgKCQeHdAMPCA6lH4ExPjGKVGeEQwEBBYctAwqEHAEBAQEBAQEDAQEBAQEBAQEBARUIEIYYhE2CQ4FjR4JUglqGVQyHJIpXNIYIhi6CC4I4jHKIE4YzEh6BDw8mghoNEQuBaCAyAYlHAQEB X-IPAS-Result: A0DBAAC9GnVXhi/XVdFbhBR9BqgRhR2HD4Z9IoV1AoE0BzwQAQEBAQEBAQERAQEBCAsLCSEvgjKCGgEBAQMBEhEdAQEsCwEECwsLAwoNHQICIQESAQUBChIGEwgKCQeHdAMPCA6lH4ExPjGKVGeEQwEBBYctAwqEHAEBAQEBAQEDAQEBAQEBAQEBARUIEIYYhE2CQ4FjR4JUglqGVQyHJIpXNIYIhi6CC4I4jHKIE4YzEh6BDw8mghoNEQuBaCAyAYlHAQEB X-IronPort-AV: E=Sophos;i="5.26,552,1459807200"; d="scan'208,217";a="224894740" Received: from mail-lf0-f47.google.com ([209.85.215.47]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 30 Jun 2016 15:13:30 +0200 Received: by mail-lf0-f47.google.com with SMTP id f6so55183155lfg.0 for ; Thu, 30 Jun 2016 06:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zf9L6U9WBin5r5+4L7fQvCll/PGAku1LtvcJWM0gGNw=; b=uKn4uIbW+RYBFJHOgsYo9wwcdWidglIfjAns1LyAC59Qk0ZIMTjrSRcMc0+PhHUOlZ r8+A12Z+ldLZVDXcfKyhonThSc4fowLbDUiGBrnmFTNUFlSu10bvMryDjdYKkZGPEUCD jOaauvMDrkQgyc3Nun5CcNIiHcE/al26dD3gepOW+a5PoGMFk130awwbG6Yz2ew7dEAT xnTAnSvMsoXXrIDXLYd5J6zmcGFe4JQWu5lrVdkb8+8ARqcul7jtuiIvdojxqbNHIlMV A66b0Hqt5C3PsR771PeUw+OV+CG8IJl7MONtRSc/xc2U4ZAVMy8olwzrk13ZMAX1pESr 6GNA== 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; bh=zf9L6U9WBin5r5+4L7fQvCll/PGAku1LtvcJWM0gGNw=; b=dxbZvwhz7WSIJ3f4ZuB+14OfuXHd7TXu1eeWNkELwFBSeyRAd3nvngvL1jnGQ9Pwtt h4/iqS5o5eUIOa8PV3FXzn1MUGdhvZDp1hExd3ezdbiM3yNSA49BVhwnI6DK1jndWuVC UohD45B7BeOf9suYWgWGnmw/QzoQDL7J5UK8lWnhv3LzBVmic8lvhSmCeDSeQnGFzjBs ZDXHKK1F/ApvK126n6LghzHOQSwVgtuNZd82gAaYCQnQrZ/0Ul+wSdyosc9wiogUrQB6 0zlhgZyDSaNw8ifvW3ayNqprF5+ITIyS2cnpsCrA1XL757YquXgsXl4GGXJSv60fQzFh GRVA== X-Gm-Message-State: ALyK8tLpYl3qk0w0eg4GmpEFLoJDpKJXgpaC6pX0mljC23Z/kYMXmY27gENWPUSlN3eIK9juheBW6HFpsdW9d4q/ X-Received: by 10.25.170.134 with SMTP id t128mr5187701lfe.133.1467292409435; Thu, 30 Jun 2016 06:13:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.91.77 with HTTP; Thu, 30 Jun 2016 06:13:28 -0700 (PDT) In-Reply-To: References: <7785E51D-EC74-4A78-8840-D4A7C18E3C56@gmail.com> From: Ivan Gotovchits Date: Thu, 30 Jun 2016 09:13:28 -0400 Message-ID: To: Yaron Minsky Cc: Dean Thompson , caml-list , Jeremy Yallop Content-Type: multipart/alternative; boundary=001a11411832d8cb1b05367ea230 Subject: Re: [Caml-list] how to encourage adoption of OCaml? --001a11411832d8cb1b05367ea230 Content-Type: text/plain; charset=UTF-8 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 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. > 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 represented as `Lwt_stream.t` or `Pipe`. Currently in both Lwt and Async the main thread 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 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 > > --001a11411832d8cb1b05367ea230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 30, 2016 at 8:12 AM, Yaron Minsky <yminsky@janestreet= .com> wrote:

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.

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 i= n 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 t= he future, that is represented as `Lwt_stream.t` or `Pipe`. Currently in bo= th Lwt and Async the main thread type is tightly coupled with the underlyin= g implementation, especially in Async (Lwt.t can be easily decoupled).=C2= =A0

y

On Jun 30, 2016 6:32 AM, "Dean Thompson&quo= t; <dean= sherthompson@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 Wor= ld OCaml, many newcomers 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

--001a11411832d8cb1b05367ea230--