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 > >