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

[Ivan Gotovchits <ivg@ieee.org>]

[-- Attachment #1: Type: text/plain, Size: 4056 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5712 bytes --]