caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Richard Jones <rich@annexia.org>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Metaprogramming features
Date: Sat, 4 Oct 2008 14:57:16 +0100	[thread overview]
Message-ID: <20081004135715.GA29077@annexia.org> (raw)
In-Reply-To: <200810041531.18370.jon@ffconsultancy.com>

On Sat, Oct 04, 2008 at 03:31:18PM +0100, Jon Harrop wrote:
> I asked if it would be worth doing so before I even attempted it and was told 
> that it would not be worth attempting by Pierre Weis. Xavier Leroy told me 
> that copyright issues in French law essentially prohibit contributions from 
> non-French programmers.

I'm collaborating at the moment with a couple of French programmers on
a [non-OCaml] FSF project, so this seems unlikely to me (and yes, both
the FSF and Red Hat provide lawyers to check this sort of thing out).

> > Where did you nurse the patch through many iterations, 
> > as the language designers asked you to fix one thing and another,
> > before the final patch was rejected?
> 
> I would like to think that the OCaml community has try..finally pinned down 
> now. It is the first example on every Camlp4 tutorial after all...

Std.finally in extlib?  I've used it precisely twice, ever, so I'm not
convinced that try/finally is the one thing missing from OCaml
that would propel it to mass adoption.

> I'm not saying that there is anything wrong with having a language 
> implementation written by language researchers for language research but 
> almost all users would benefit enormously from a variety of simple 
> improvements that the community could easily implement themselves were it 
> feasible to get changes absorbed upstream more quickly. Now that OCaml is 
> gaining traction in industry there are also a growing number of people 
> willing to throw money around to get improvements made and we could all be 
> benefitting from that.

You still don't get the whole open source thing though.  You need to
make the patches yourself, or get FF Consultancy to pay someone to
develop them.  Deep compiler changes don't just happen because someone
demands them.  Whether we're talking about INRIA's busy researchers or
volunteers maintaining Perl & Ruby in their spare time, they don't
have time to just implement stuff because people shout loudly.
Instead they review patches submitted through the standard bug
tracking system.

Despite your claims, there are lots of features currently being
tracked through mantis.  I've submitted a couple of minor ones myself,
both of which will appear in 3.11.  But I didn't just demand they
happen - for both of them I submitted patches, listened to feedback,
modified things ...

  http://caml.inria.fr/mantis/
  http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/

So here's an idea:

(1) Start a project to list all the things you think are missing from
the compiler or language.  I'd join this project, because I've got a
few things of my own.

(2) Enumerate them on a wiki or editable web page somewhere, ask
others to join, argue about the features you think are priorities.

(3) WRITE PATCHES to implement them in the CVS version of the OCaml
compiler (or library, or wherever they need to be implemented).

(4) Submit the patches, and detailed rationales for the changes,
through the bugtracker.

(5) Listen to feedback, modify your patches as appropriate.  Some will
get rejected, some accepted straightaway, most will need to go through
many iterations.

When you've done all the above, in about a year I would say, and
nothing has been accepted, then you will be in a position to make wild
claims about OCaml upstream being too slow for your liking.  And you
can fork the project to make FlyingCaml++ the way you want it (ain't
open source great like that? -- try forking F# some time and find out
how hard the lawyers come down on you).

Rich.

-- 
Richard Jones
Red Hat


  reply	other threads:[~2008-10-04 13:57 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-03 14:34 Jacques Carette
2008-10-03 15:09 ` [Caml-list] " Dario Teixeira
2008-10-04  2:00   ` Jon Harrop
2008-10-04  9:03     ` David Teller
2008-10-04 14:22       ` Jon Harrop
2008-10-06 14:06     ` Brian Hurt
2008-10-06 15:56       ` Jon Harrop
2008-10-06 16:46         ` Chung-chieh Shan
2008-10-07  0:17           ` [Caml-list] " Jon Harrop
2008-10-07 12:49             ` Nicolas Pouillard
2008-10-07 15:36               ` Jon Harrop
2008-10-07 16:31                 ` Jacques Carette
2008-10-03 16:01 ` [Caml-list] " David Teller
2008-10-03 21:14   ` Paolo Donadeo
2008-10-04  2:17   ` Jon Harrop
2008-10-04  9:10     ` David Teller
2008-10-04  0:49 ` Stefano Zacchiroli
2008-10-04  2:03   ` Jon Harrop
2008-10-04  8:23     ` Richard Jones
2008-10-04 14:31       ` Jon Harrop
2008-10-04 13:57         ` Richard Jones [this message]
2008-10-04 19:41           ` Jon Harrop
2008-10-04 19:04             ` Richard Jones
2008-10-05  1:05               ` Jon Harrop
2008-10-06 16:54               ` Chung-chieh Shan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081004135715.GA29077@annexia.org \
    --to=rich@annexia.org \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).