Version française
Home     About     Download     Resources     Contact us    
Browse thread
Metaprogramming features
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Richard Jones <rich@a...>
Subject: Re: [Caml-list] Metaprogramming features
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