[ocaml-platform] The OCaml Platform

[Sylvain Le Gall]

2013/2/12 Yaron Minsky <yminsky at janestreet.com>:
> I understand what it would mean to have an interface to Lwt or Async,
> but what would it mean to have an interface to Core?  Do you mean just
> to have a skin for fileutils that follows Core's conventions?
>

Let's take an example that I know and that I already have thought
about (sorry if it is not Core, but Lwt).

Imagine that I want to use fileutils "ls":
1. val ls : filename -> filename list

It should look like this with lwt:
2. val ls: filename -> (filename list) Lwt.t (I think, Lwt.t being a monad)

So the question would be how to transform 1. into 2. This is quite
important, because you would like to not mix blocking operation with
non-blocking one and have a quite common style in your application.

In the case of Lwt, the solution is pretty straight forward, you just
use a thread (Thread) to wrap 1. and produce 2.

I think the overall question is "do we wish to have a common style for
non-stdlib features", e.g. monads, file descriptor et al. I don't
think this is mandatory but can be a nice long term goal.

But maybe I am going too far, and the point of OCaml Platform is just
to have  a "set of libraries", tested, packaged together and released
every 6 months (which is already an ambitious goal). If this is the
case, please ignore my question -- I'll be already extermly happy to
see an OCaml Platform in 6 months.


> To say the obvious, one can use Core alongside with other libraries
> without issue.

That is a good thing ;-)

>
> y
>
> On Tue, Feb 12, 2013 at 6:02 AM, Sylvain Le Gall
> <sylvain+ocaml at le-gall.net> wrote:
>> 2013/2/11 Yaron Minsky <yminsky at janestreet.com>:
>>> On Mon, Feb 11, 2013 at 3:02 PM, Sylvain Le Gall
>>> <sylvain+ocaml at le-gall.net> wrote:
>>>> 2013/2/11 Amir Chaudhry <amc79 at cam.ac.uk>:
>>>>> Dear Platform list,
>>>>>
>>>>> Welcome to those who've joined the list.  Here are some additional notes about the Platform.
>>>>>
>>>>> ## About the Platform ##
>>>>>
>>>>> The OCaml Platform combines the core OCaml compiler with a coherent
>>>>> set of libraries, tools, docs and other resources.  It is a project
>>>>> led by OCaml Labs in Cambridge, UK and the requirements and
>>>>> direction of the Platform will be guided by the major stakeholders.
>>>>> We've already spoken with Jane Street and Citrix, and intend to
>>>>> work closely with other Consortium members too.
>>>>>
>>>>> It is envisaged that the Platform will initially bundle OCaml 4.01
>>>>> together with a specific set of libraries.  Package management,
>>>>> continuous integration and support for external libraries will be
>>>>> provided by OPAM (see below).  The other components of v0.1 will be
>>>>> settled on through discussion with the major stakeholders and on
>>>>> this list.  Since components will need to work well with each
>>>>> other, they should not be too numerous at first, and authors should
>>>>> be aware that some future work might be required as the Platform
>>>>> develops.
>>>>
>>>> Does it mean they will have to provide interfaces with e.g. monads of
>>>> core? (which will probably make everything depends on Core) Or do you
>>>> think we will try to have some kind of higher level requirement, like
>>>> to have at least a 3rd party module that can integrate?
>>>
>>> Core is designed to interoperate with other OCaml libraries.
>>> Obviously, I like the conventions of Core and would like to encourage
>>> people to use them.  But I haven't heard anyone propose any kind of
>>> draconian rule to require following Core's interface standards.
>>>
>>
>> No offense meant, this was just an example. I would be glad to provide
>> a 3rd party library that interface with core, but would like to not
>> put it as a build dependencies of the initial library.
>>
>> E.g:
>> - fileutils -> the standard library
>> - fileutils-core -> the interface to core.
>> - fileutils-batteries, fileutils-lwt -> the interfaces to batteries and  lwt
>>
>>>> E.g. considering one of my library "fileutils", does it mean I have to
>>>> make fileutils depends on Core or should I just provide a method
>>>> "next" to iterate over the results of "ls"?
>>>>
>>>>> We plan to develop compiler enhancements to assist the development
>>>>> of software using the Platform -- for example, some variety of
>>>>> namespaces would likely provide benefits when using lots of
>>>>> modules.  These projects will be discussed individually in groups
>>>>> headed by experts.
>>>>>
>>>>
>>>> Does it mean included libraries/tools will have to use this specific
>>>> enhancements?
>>>
>>> Speaking for no one but myself, I think that if we get a good
>>> namespace system for OCaml, we should probably require that libraries
>>> in the platform use it.  Agreeing on partitioning names seems like a
>>> fundamental bit of work that a platform requires.
>>>
>>> I would think that there are other things that one would want to
>>> require, like good use of documentation facilities.
>>>
>>>>> ## Platform availability ##
>>>>>
>>>>> We aim for the Platform to be available via other distributions,
>>>>> e.g. Debian, which necessitates binary packages.  Documentation of
>>>>> the included libraries will also be important (see below) and
>>>>> should aid standardisation.
>>>>
>>>> I think we should be more precise on this:
>>>> 1. target stable distribution of linux Distro (e.g. Debian Stable) at
>>>> the time of the release
>>>> 2. will not aim at being officially part of the Distro (i.e. not try
>>>> to have an "ocamlot" package inside Debian)
>>>> 3. will not interfere with the official package coming from the
>>>> distribution (e.g. you can install "ocaml" and
>>>> "libfileutils-ocaml-dev" AND "ocamlot" on the same computer).
>>>>
>>>> Point 2. is quite important, because it is clearly an opportunity to
>>>> provide a working dev env to people using Debian Stable and that want
>>>> to have the latest greatest packages (whereas in Debian, you'll
>>>> probably lagging a bit in term of "latest").
>>>>
>>>>>
>>>>> ## Documentation ##
>>>>>
>>>>> As part of the platform efforts we aim to improve the documentation
>>>>> generation of OCaml tools.  The aim is to support the OCaml
>>>>> Platform with fully cross-referenced documentation from source
>>>>> code, including the ability to incorporate interactive tutorials
>>>>> using the js_of_ocaml compiler.  This would also be combined with a
>>>>> single cross-referenced website.
>>>>>
>>>>> ## Testing and benchmarking ##
>>>>>
>>>>> A continuous integration framework, based on OPAM, will form part
>>>>> of the Platform infrastructure.  We're calling this infrastructure
>>>>> "OCamlot". OPAM packages can be automatically tested upon
>>>>> submission and reports sent back to maintainers.  OCamlot will
>>>>> execute basic unit tests and also, in later versions, integrate
>>>>> benchmarking.  The build infrastructure is intended to run tests on
>>>>> the full range of community packages in OPAM by using secure
>>>>> virtualization under Citrix XenServer.  If you submit a package,
>>>>> you will be rewarded with regular regression tests across many
>>>>> diverse operating systems and platforms.
>>>>>
>>>>> ## Releases and updates ##
>>>>>
>>>>> Upon the first release of the Platform, updates and improvements will form a six-monthly cycle.
>>>>>
>>>>
>>>> I propose to have some kind of "moral contract" with upstream, that
>>>> will need to backport important patches to the current version of
>>>> "ocamlot".
>>>>
>>>>
>>>> Regards
>>>> Sylvain
>>>>
>>>>> Best wishes,
>>>>> Amir
>>>>> _______________________________________________
>>>>> Platform mailing list
>>>>> Platform at lists.ocaml.org
>>>>> http://lists.ocaml.org/listinfo/platform
>>>> _______________________________________________
>>>> Platform mailing list
>>>> Platform at lists.ocaml.org
>>>> http://lists.ocaml.org/listinfo/platform