[ocaml-platform] The OCaml Platform

Tue Feb 12 14:15:33 GMT 2013

On Tue, Feb 12, 2013 at 8:58 AM, Anil Madhavapeddy <anil at recoil.org> wrote:
> The most pressing problem is with camlp4 extensions that generate
> code.  Right now, things break if Core.Std is open, and vanilla OCaml
> library calls are used (e.g. List.flatten).
>
> Namespaces offer a solution to this by letting extensions explicitly
> open a particular standard library without caring what's happening
> around them.  As it stands, we need to be really careful about code
> generation, or have camlp4 options to toggle Core-style code on/off.

I don't see why this would be a problem with fileutils.  If you want
to use Core's naming conventions and organization, you open Core.Std.
If not, you can just pick and choose the modules you want from
Core.Std.  But either way, I don't see why you need to specialize
fileutils to be usable with Core.  Can you give a concrete example of
an incompatibility?

Similarly with the syntax extensions.  Core needs syntax extensions to
build, but it doesn't need them to use Core.

Now, if you want to interoperate with Core maximally well, i.e., you
want to be able to use Core's functors smoothly and easily, or you
want to use the interface components in Core like Sexpable,
Comparable, Hashable, etc, then you do need to depend on Core.  But
that seems like a fundamenatal issue, and not one that can be
ameliorated by namespaces.

> -anil
>
> On 12 Feb 2013, at 13:49, Yaron Minsky <yminsky at janestreet.com> wrote:
>
>> 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
>> _______________________________________________
>> Platform mailing list
>> Platform at lists.ocaml.org
>> http://lists.ocaml.org/listinfo/platform
>>
>