From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA12630 for caml-red; Wed, 19 Jul 2000 17:46:58 +0200 (MET DST) 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 VAA22763 for ; Tue, 18 Jul 2000 21:00:26 +0200 (MET DST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e6IJ0Kv16652 for ; Tue, 18 Jul 2000 21:00:22 +0200 (MET DST) Received: by suburbia.net (Postfix, from userid 110) id 144486C4C2; Wed, 19 Jul 2000 05:00:11 +1000 (EST) To: caml-list@inria.fr Subject: moderation of caml-list Cc: proff@iq.org From: Julian Assange Date: 19 Jul 2000 05:00:09 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: weis@pauillac.inria.fr Can caml-list please be made unmoderated? The delay in posting approval is clearly slowing down the speed of intellectual interchange. People exchange ideas because there is some perceived value to them in doing so. They believe it will help them progress in some way with their lives (even if that is by helping others). Since progress is built upon this interchange of ideas, where there there is slowing down or impediment on it, there is also a retardation of the progress it creates. Less philosophically, if a caml-user needs advice from the caml community to continue camling that isn't forthcoming, then their progress is (a) clearly going to be retarded, and (b) during the period waiting for advice they will spend their time on something that isn't caml. So during any unit period of time, less caml code will be written. Further, rapid exchange of ideas creates community. Yes, it can devolve into a bar-room. But if a bar has nice people in it, then over time, it develops a healthy community due in part to little personal interchanges. The haskell users list is successful in this regard because it is unmoderated. I don't think the argument can be held that ocaml users are somehow more uncouth simply because they are ocaml users, or perhaps more likely to be French ;) Since Xaviar has set up a source-forge account, I suggest that its mailing list management features be taken advantage of. Failing this, I run a number of mailing lists and am willing to run an additional one. I suggest splitting the lists up into: caml-announce -- for software announcements caml-research -- for infrequent, lengthy language design issues, particularly note worthy posts to caml-users can be bounced here. caml-users -- for everything else As a side note, I'd like to again express my desire for type-inferment of side-effects and exceptions in closures containing them or references to functions that do (and so on). Apart from making the code easier to read and debug this would also permit: a) type assertions as to the functional purity of closures b) easier `common closure/function-elimination' c) common closure/function elimination between modules Currently (a(), a()) can not be optimised to perform only one invocation of a(). Cheers, Julian.