Re: Syntax for label (and more)

[Markus Mottl <mottl@miss.wu-wien.ac.at>]

> - User contributions to the standard library: I'm open to concrete
> proposals on this.  One of the reasons why the OCaml standard library
> modules have remained minimal is that it's often hard to know what
> would be useful to a significant fraction of users (as opposed to
> functions that only their author is going to use).  Also, we must be
> careful to keep the standard library manageable, e.g. with consistent
> naming conventions and good documentation.  For all these aspects,
> some kind of peer reviewing of new extensions sounds good.

There are some questions concerning upgrading the standard library that
should be cleared before, I think:

Firstly, is there already a specific plan for the further development of
the standard library? Adding a function here and there is unlikely to lead
to consistent functionality. There is probably already a TODO-list for the
next "big" steps in compiler development, but is this also the case for the
libraries?

Maybe a "two way" approach would be appropriate, where also users might
want to help: in one branch we just (conservatively!) extend the current
standard library, letting the main developers decide when to adopt the
changes, in another we create completely new components, which might either
provide for new functionality or replace older modules at some point of
time (again, the decision for adopting new modules or declaring old ones
obsolete should be up to the main developers).

The latter "branch" raises the following questions:

  - Which abstract data types, what kind of special purpose libraries are
    wanted/required in the distribution?

  - Would it be a good idea to provide for different implementations for
    the same interface if this has significant impact on performance or is
    one "generally acceptable" implementation the better way?

  - Version control for the developers is fine - but what about the users?
    How can we guarantee that they do not easily end up with legacy
    software if their systems make use of older libraries?

The last part, for example, seems to uncover a problem that has already
been discussed on the mailing list from time to time: packaging of
libraries and dependency management (there are also dependencies on
versions).

If this problem is conveniently solved, we won't have to be so reluctant
changing things in the standard library. Disk space is really not a topic
anymore today so having subdirectories in the distribution that contain
older releases of libraries will surely not hurt.

Users who need to guarantee that their older systems compile with new
releases could possibly do so, for example, by writing

  open Stdlib_V3_1

or similar at the top of their files (would require that directories can be
treated like a module with submodules) - but maybe there are better ways to
do this?


For the beginning, we could try the "small" branch first to see whether the
nice ideas (collaborative work, peer reviews) really work. So if nobody
objects, would it be possible to set up a directory at "camlcvs", where
users could experiment with "their" standard library? - Of course, each
user would have to ask personally for access to this account, but this
shouldn't be a problem, I hope...

Comments?

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl