moderation of caml-list

moderation of caml-list

[Julian Assange]

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.

Re: moderation of caml-list

[Markus Mottl]

On Wed, 19 Jul 2000, Julian Assange wrote:
> 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:

Although I would also like to see something like this, I fear that
implementing a "good-enough" solution would draw human resources that are
currently probably better invested elsewhere...

In any case: having information of this sort at compile time would allow
some really nice transformations/optimizations, much more powerful ones
than just factoring of common subexpressions or lifting of expressions.

E.g., one could safely apply transformations like partial evaluation,
deforestation/fusion or automatic introduction of accumulators for
tail-recursiveness, etc...

For people interested in program transformations, here is a nice overview:

  @Article{Pettorossi-Proietti96,
    key =          "Pettorossi \& Proietti",
    author =       "Alberto Pettorossi and Maurizio Proietti",
    title =        "Rules and Strategies for Transforming Functional and
                    Logic Programs",
    journal =      "ACMCS",
    volume =       "28",
    number =       "2",
    pages =        "360--414",
    month =        jun,
    year =         "1996",
    annote =       "Many references.",
  }

You can get it from here:  http://www.iasi.rm.cnr.it/~proietti/reports.html

I especially like the example where the straightforward (exponential)
fibonacci function is transformed by a series of automatable rule
applications to one which runs in logarithmic time (yes, I mean
*logarithmic*, not linear - I didn't know of this trick either...).
Such superexponential speedups are indeed very attractive! 8-)
Unfortunately, some transformations require purity...

Best regards,
Markus Mottl

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