Re: [Caml-list] [OSR] OCaml Standard Recommandation Process

[Jon Harrop <jon@ffconsultancy.com>]

On Sunday 27 January 2008 21:47:47 Yaron Minsky wrote:
> On Jan 27, 2008 4:07 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> > Would it not be much easier and much more productive to simply fork the
> > OCaml
> > distribution and address these issues at source? You could then address
> > many
> > other issues like improving the stdlib, adding a "try..finally" construct
> > to
> > the language, adding features to help with the brittle binding problem
> > and opening the compiler's internal representations to the outside world.
>
> That seems like a fairly awful idea to me.

Agreed but I see no other way to keep OCaml alive and moving in a direction 
that is beneficial to its community.

> Trying to develop the core language away from the confines of INRIA seems
> expensive and unlikely to go well.

Sophisticated renovations of the type system might not succeed but we're 
talking about much more mundane features here. Just looking at text, we might 
want:

. Folds in the String module.
. Functions to read whole files as a string or list of lines.
. Either "try..finally" or "use" bindings or combinators to automate closing.
. Immutable strings.
. Ropes.
. Unicode.
. More efficient pattern matching.

These have all been available for years in the form of many incompatible 
extensions and will continue to be under-used until they are integrated into 
OCaml itself.

There are also many features that I would like to steal from other languages:

. The IDisposable interface from .NET and F#'s "use" bindings.
. F#'s computation expressions: a syntax for monadic style in ML.
. Integrated OpenGL-based graphics.

and some more involved ones like operator overloading.

> The INRIA team understands the core of the language like no one 
> else, after all, and it will be hard to replace that expertise.

OCaml's researchers at INRIA are unquestionably talented but they have made it 
quite clear that polishing the public OCaml distribution is not their job. 
Moreover, they are grossly over-qualified for most of this work. We don't 
need a world expert in type theory to write String.fold_right for us: it 
would be a waste of their time and constantly working around its absence is a 
waste of ours. So we have different goals and (IMHO) have reached the point 
where their developments are arguably doing more harm than good for many us.

If we want a more robust and feature complete OCaml then we must develop it 
ourselves. Luckily the community has already done most of the hard work and 
we just need to integrate this work into a new standardized OCaml 
distribution and get the package maintainers to migrate to it.

With so many trivial changes to make this seems like a no-brainer to me. 
Indeed, we've had many interesting threads here over the past few years and 
this is our chance to put them into action. Look at all of the great 
suggestions for optimizations that came out of the thread about MLton's 
performance, for example. We can implement some of them. Look at the 
outstanding bugs that were cited recently. We could fix many of them.

> I do think there is value in outside companies thinking carefully about a
> limited set of improvements that (a) can only be fixed in the core language
> and (b) would make it easier for outsiders to add necessary features.

You need a reasonable and objective definition of "can only be fixed in the 
core language" because, of course, you can ad-hoc many things with camlp4 but 
the results are much harder to maintain and will never gain the traction they 
deserve. For example, I am not willing to have to change my compile lines, 
learn to interpret different compiler output and break my other tools just to 
get a "try..finally" construct but I would love to see it added to the OCaml 
language and implemented in the tools.

Improving the standard library is high on my list. Sources of stack overflows 
should be removed. The library should be filled out, e.g. so that all modules 
implementing containers adhere to a suitable signature and Set/Map-compatible 
modules are provided for all basic types (e.g. Int, Float).

As for making it easy for outsiders to add necessary features, perhaps there 
is something we can do to weaken these brittle bindings by automating the use 
of functors in a new intermediate representation and distribute that instead. 
As the package maintainers have already said, this would make their lives 
easier too!

> One role I would like to see the caml team take upon itself is that of
> blessing standardization efforts.  If INRIA had a link on its site to a
> recommended batteries-included distribution, that would help the community
> coalesce around that distribution.  Obviously trying to choose winners in
> this way is tricky and not to be done lightly, but I do think there's a
> good chance that it will become important.

If INRIA's blessing would help to persuade the package maintainers that we 
have consensus to move forward with a new upstream source for the OCaml 
distribution then I agree.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e