Re: [Caml-list] how to encourage adoption of OCaml?

[Dean Thompson <deansherthompson@gmail.com>]

Yaron, since you describe janestreet/lwt-async as "an experiment in this direction”, 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 <yminsky@janestreet.com> 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 <ivg@ieee.org> wrote:
>> 
>> 
>> 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 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" <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 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 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
>> 
>>