[ocaml-platform] The OCaml Platform

[Yaron Minsky]

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?

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

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