From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA04957 for caml-redistribution@pauillac.inria.fr; Tue, 21 Mar 2000 15:38:41 +0100 (MET) Resent-Message-Id: <200003211438.PAA04957@pauillac.inria.fr> Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA13610 for ; Tue, 21 Mar 2000 02:29:31 +0100 (MET) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id CAA06963; Tue, 21 Mar 2000 02:29:30 +0100 (MET) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id CAA13482; Tue, 21 Mar 2000 02:29:25 +0100 (MET) From: Markus Mottl Message-Id: <200003210129.CAA13482@miss.wu-wien.ac.at> Subject: Re: Syntax for label (and more) To: Xavier.Leroy@inria.fr (Xavier Leroy) Date: Tue, 21 Mar 2000 02:29:24 +0100 (MET) Cc: caml-list@inria.fr (OCAML) In-Reply-To: <20000315213941.19110@pauillac.inria.fr> from "Xavier Leroy" at Mar 15, 2000 09:39:41 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-From: weis@pauillac.inria.fr Resent-Date: Tue, 21 Mar 2000 15:38:41 +0100 Resent-To: caml-redistribution@pauillac.inria.fr > - 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