moderation of caml-list

[Julian Assange <proff@iq.org>]

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.