[OSR] Caml Community Code

[OSR] Caml Community Code

[Jonathan Bryant]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

List,

Despite all the great ideas on the [OSR] threads, we seem to be getting
nowhere and talking ourselves to death bickering about implementation
details of code that hasn't even been written yet.  I think the only thing
we can agree on is that tools for use by the community should be written by
the community.  Because of that, we need to start writing them: the best way
to find out what works is to try.

I've created a SourceForge project called Caml Community Code here (
http://sourceforge.net/projects/camlcode) where we can put any code for
community OCaml tools.  The fact that we can't hack the OCaml language
itself (due to French copyright law) seems to have unfortunately caused the
community to not hack together on other tools _for_ the language.  With this
project everyone can hack on the tools we'll (hopefully) end up using every
day, rather than having INRIA or one person try to build something that
satisfies everyone.  If you have code for tools (I know someone at least has
some code for a package manager), please put it in the repository so we can
all see and work on it _as as community_.

Regarding the package manager discussion, what we need is a few functioning
prototypes.  Later we can go back and cherry pick features we like and merge
them down to just two to develop a little more, and finally pick one.  I
also think we should have one CamlP4 grammar with all the community's agreed
upon "standard" syntax extensions (sort of a "new revised" syntax?), a set
of "standard" ocamlbuild plugins, and "standard" interfaces (XML parser,
etc.), all of which can be stored in the project as well.

I was waiting for the project to get approved before sending this out (it
just came through this morning), so I'll go ahead and make a temporary
directory layout.

--Jonathan

[-- Attachment #2: Type: text/html, Size: 1996 bytes --]

Re: [Caml-list] [OSR] Caml Community Code

[blue storm]

Sylvain Le Gall has announced at the meeting that he would provide a
server with basic development tools. I think it would be pertinent to
host such projects there.
(Moreover, sourceforge is not free, baah :p )
But I don't know how his server-building is going.

More generally, I totally agree on the "get things done" idea.
I'm willing to help in the camlp4 area. A common place for up-to-date
camlp4 extensions (akin to what martin jambon provides for ocaml <=
3.09) would be a very good thing.

On 1/31/08, Jonathan Bryant <watersofmemory@gmail.com> wrote:
> List,
>
> Despite all the great ideas on the [OSR] threads, we seem to be getting
> nowhere and talking ourselves to death bickering about implementation
> details of code that hasn't even been written yet.  I think the only thing
> we can agree on is that tools for use by the community should be written by
> the community.  Because of that, we need to start writing them: the best way
> to find out what works is to try.
>
> I've created a SourceForge project called Caml Community Code here (
> http://sourceforge.net/projects/camlcode) where we can put any code for
> community OCaml tools.  The fact that we can't hack the OCaml language
> itself (due to French copyright law) seems to have unfortunately caused the
> community to not hack together on other tools _for_ the language.  With this
> project everyone can hack on the tools we'll (hopefully) end up using every
> day, rather than having INRIA or one person try to build something that
> satisfies everyone.  If you have code for tools (I know someone at least has
> some code for a package manager), please put it in the repository so we can
> all see and work on it _as as community_.
>
> Regarding the package manager discussion, what we need is a few functioning
> prototypes.  Later we can go back and cherry pick features we like and merge
> them down to just two to develop a little more, and finally pick one.  I
> also think we should have one CamlP4 grammar with all the community's agreed
> upon "standard" syntax extensions (sort of a "new revised" syntax?), a set
> of "standard" ocamlbuild plugins, and "standard" interfaces (XML parser,
> etc.), all of which can be stored in the project as well.
>
> I was waiting for the project to get approved before sending this out (it
> just came through this morning), so I'll go ahead and make a temporary
> directory layout.
>
> --Jonathan
>

Re: [Caml-list] [OSR] Caml Community Code

[Stefano Zacchiroli]

On Thu, Jan 31, 2008 at 05:25:20PM +0100, blue storm wrote:
> Sylvain Le Gall has announced at the meeting that he would provide a
> server with basic development tools. I think it would be pertinent to
> host such projects there.
> (Moreover, sourceforge is not free, baah :p )
> But I don't know how his server-building is going.

It is going ... we have set up a small time of people which is setting
up the machine. We already have the forge and some other services, but
it is still premature to announce it to the wide public for testing.
Stay tuned.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time

Re: [Caml-list] [OSR] Caml Community Code

[Jon Harrop]

On Thursday 31 January 2008 20:53:43 Stefano Zacchiroli wrote:
> On Thu, Jan 31, 2008 at 05:25:20PM +0100, blue storm wrote:
> > Sylvain Le Gall has announced at the meeting that he would provide a
> > server with basic development tools. I think it would be pertinent to
> > host such projects there.
> > (Moreover, sourceforge is not free, baah :p )
> > But I don't know how his server-building is going.
>
> It is going ... we have set up a small time of people which is setting
> up the machine. We already have the forge and some other services, but
> it is still premature to announce it to the wide public for testing.
> Stay tuned.

Will your or Jonathan Bryant's distros include an enhanced OCaml or are they 
collections of third party libraries only?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] [OSR] Caml Community Code

[Stefano Zacchiroli]

On Thu, Jan 31, 2008 at 09:38:32PM +0000, Jon Harrop wrote:
> Will your or Jonathan Bryant's distros include an enhanced OCaml or are they 
> collections of third party libraries only?

Jon, pretty please, stop it. You already know that we (Debian), me
(Zack), and whatever else entities which are associated to my free will
are *NOT* going to fork OCaml or any of its parts. (The reason being
that I don't think it would be beneficial to the community in any way at
this point, but this motivation is OT here.)

Now you can go back, read the minutes of the meeting and other messages
from Sylvain and you can find out by yourself that we are not going to
provide novel software, but rather services.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time

Re: [Caml-list] [OSR] Caml Community Code

[Jon Harrop]

On Friday 01 February 2008 08:13:40 Stefano Zacchiroli wrote:
> On Thu, Jan 31, 2008 at 09:38:32PM +0000, Jon Harrop wrote:
> > Will your or Jonathan Bryant's distros include an enhanced OCaml or are
> > they collections of third party libraries only?
>
> Jon, pretty please, stop it. You already know that we (Debian), me
> (Zack), and whatever else entities which are associated to my free will
> are *NOT* going to fork OCaml or any of its parts. (The reason being
> that I don't think it would be beneficial to the community in any way at
> this point, but this motivation is OT here.)

Sure. Will either of the other community OCamls be forking OCaml?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] [OSR] Caml Community Code

[Christopher L Conway]

Jon,

So far as I can tell, there is exactly one person on this mailing list
who is interested in forking OCaml. So the relevant questions is: are
*you* going to be forking OCaml? I would strongly urge you not to.

Chris

On Feb 1, 2008 4:14 AM, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Friday 01 February 2008 08:13:40 Stefano Zacchiroli wrote:
> > On Thu, Jan 31, 2008 at 09:38:32PM +0000, Jon Harrop wrote:
> > > Will your or Jonathan Bryant's distros include an enhanced OCaml or are
> > > they collections of third party libraries only?
> >
> > Jon, pretty please, stop it. You already know that we (Debian), me
> > (Zack), and whatever else entities which are associated to my free will
> > are *NOT* going to fork OCaml or any of its parts. (The reason being
> > that I don't think it would be beneficial to the community in any way at
> > this point, but this motivation is OT here.)
>
> Sure. Will either of the other community OCamls be forking OCaml?
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/products/?e
>
> _______________________________________________
>
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

Re: [OSR] Caml Community Code

[Sylvain Le Gall]

On 01-02-2008, Christopher L Conway <cconway@cs.nyu.edu> wrote:
> Jon,
>
> So far as I can tell, there is exactly one person on this mailing list
> who is interested in forking OCaml. So the relevant questions is: are
> *you* going to be forking OCaml? I would strongly urge you not to.
>

Funny, on the contrary, i would strongly urge Jon to do it... He asks
some many times for a fork when most of the people i know are not
interested in -- to my mind. I think it is important that he tries to do
it because:
* he will be able to face the huge amount of work done by the INRIA
* he will have to create a community around his fork
* he will have to handle many differents arch -- some of them pretty
 exotic
* he will stop sending mail about it

Maybe after considering all this, he will simply stop to ask for a fork.

I think forking is a *BAD* thing to do -- but if Jon really think it is
worth, i really think he should try rather than asking for it in half of
the mail he sends.

<ask for pardon>
I hereby declare that this will be my only mail about this subject.
</ask for pardon>

Regards,
Sylvain Le Gall

Re: [Caml-list] [OSR] Caml Community Code

[Jon Harrop]

On Friday 01 February 2008 13:56:36 Christopher L Conway wrote:
> Jon,
>
> So far as I can tell, there is exactly one person on this mailing list
> who is interested in forking OCaml.

We should clarify exactly what we mean by "forking OCaml".

I get the impression that you are asking if I want to make a replica of 
INRIA's OCaml, diverge its evolution and steal as many existing OCaml users 
as possible.

> So the relevant questions is: are *you* going to be forking OCaml?

I want to improve OCaml and I am evaluating how this might be done. Forking is 
one possibility.

One thing I would like to do is try to reconcile existing "OCaml-derived" 
distributions, taking the best from each of them. I am happy to call 
these "forks" but perhaps that has bad connurtations.

For example, Alain Frisch recently said:

  "In particular, we have our locally-patched version of OCaml and all the 
third-party libraries (either in source or binary form) in the repository."

To me, that means LexiFi forked OCaml for their own purposes. Many other 
industrial users have also forked OCaml. More importantly, these forks are 
often degenerate: they reimplement the same missing functionality, often in 
slightly different and incompatible ways.

I would like to encourage existing users to go public with their own forks so 
that we can reconcile them in order to build a single, newer, better, 
enhanced OCaml that everyone is free to share.

Lots of other people are thinking along similar lines but I, for one, am not 
at all clear on who is doing what and, in particular, what exactly their 
goals are.

For example, perhaps many (most?) of OCaml's issues can be addressed without 
altering the language by retrofitting an enhanced standard library onto 
OCaml. Perhaps this can be done transparently (i.e. without changing compile 
lines or code) in such a way that we can all share it compatibly (i.e. 
without breaking the brittle bindings) and we are all free to contribute to 
it. This would be fantastic! Perhaps that is what "Community OCaml" is all 
about but, from what I have read, heard and watched, I believe their effort 
will not implement this transparently, i.e. it will be invasive because they 
do not wish to supercede the stdlib (either by patching it or by automating 
the inclusion of augmentations). I would rather have something transparent 
because it would let users solve their problems more easily.

> I would strongly urge you not to. 

May I ask you to explain what exactly you mean and why you want to actively 
discourage such work? I have been assuming that some people are worried about 
having the relatively-small OCaml community fragmented across competing OCaml 
distributions but perhaps I am wrong.

Perhaps it will also help if I try to enumerate some of the issues that I 
would like to address. Many of OCaml's issues are trivial and have already 
been fixed:

. OCaml does not have a "try..finally" or "unwind-protect" contruct even 
though many other languages have shown that this is extremely useful and 
OCaml's "immigrants" will sorely miss it. Implementing this missing feature 
as a syntactic construct is so trivial that it is everyone's first tutorial 
on using camlp4. But working around this using a non-standard camlp4 macro is 
not a production-quality solution. It requires all compile commands to be 
altered, changes the compiler's responses to all errors and breaks developer 
tools (e.g. the Emacs mode). The production-quality solution is to alter 
either the language itself and its tools (i.e. hack the compiler) or to at 
least add a try_finally combinator to the standard library.

. OCaml's standard library could be improved a great deal. Easy-to-use 
functions for reading files would be enormously beneficial. Many of the 
current modules (e.g. String) are "missing" many functions. The efficiency of 
some of the implementations (e.g. Set) can be greatly improved.

. OCaml's top-level runs interpreted bytecode and, consequently, is many times 
slower than the interactive sessions of "competing" language implementations 
like SBCL (Lisp) and F#. Alain Frisch has already implemented a native-code 
top-level for OCaml called "ocamlnat" in his "natdynlink" fork of OCaml. I 
found this extremely useful and would like it to be easier for other people 
to benefit from this work.

Ultimately, I would also like to address some of OCaml's more fundamental 
problems but these are much harder to solve:

. OCaml's approach to bindings are a great way to avoid the angst of broken 
ABIs but the approach does not scale. Perhaps a better solution would be for 
the compiler to automate the generation of "used" interfaces and 
transparently go via functors when interfacing to libraries. This would 
loosen the bindings without completely breaking them as C does, making it 
possible to use ordinary package systems with lots of packages and making it 
much easier for people like me to distribute closed-source libraries to OCaml 
users.

. OCaml's FFI is much harder to use reliably compared to many other languages 
(C, C++, C#, F#, Lisp). It should be possible to load a C DLL and use it 
directly from OCaml without having to write and compile C stubs. Same goes 
for C++ and other languages but those are harder. LLVM may well be the holy 
grail for this.

. OCaml's lack of overloading is an impediment when writing numerical code 
that uses many different types.

. OCaml lacks some obvious types like 32-bit floats as a general storage 
format.

. OCaml lacks arbitrary unboxing of types which makes it harder to optimize 
certain kinds of code (e.g. FFTs) and impossible to write efficient 
interfaces to some libraries (e.g. OpenGL).

This raises two important questions for me:

1. Is anyone trying to transparently augment the stdlib?

2. What does LLVM facilitate for us?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] [OSR] Caml Community Code

[Jonathan Bryant]

[-- Attachment #1: Type: text/plain, Size: 2189 bytes --]

On Fri, Feb 1, 2008 at 1:07 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

[...snip...]

For example, perhaps many (most?) of OCaml's issues can be addressed without
> altering the language by retrofitting an enhanced standard library onto
> OCaml.


I'll be honest and say I usually ignore your pontificating, but for once I
agree totally.


> Perhaps this can be done transparently (i.e. without changing compile
> lines or code) in such a way that we can all share it compatibly (i.e.
> without breaking the brittle bindings) and we are all free to contribute
> to
> it. This would be fantastic!


That would be fantastic, but...


> I believe their effort
> will not implement this transparently, i.e. it will be invasive because
> they
> do not wish to supercede the stdlib (either by patching it or by
> automating
> the inclusion of augmentations).


I think this this is more likely the case.


> I would rather have something transparent
> because it would let users solve their problems more easily.


 I think that backwards-incompatibility, despite what INRIA may say, is not
terribly important.  Let us not forget that they set a precedent when they
released a incompatible and scantily documented, yet significantly improved,
CamlP4 unannounced in 3.10.

I think that if the community wrote a new, significantly improved but
incompatible standard library and handed it to INRIA, INRIA would be hard
pressed to find a reason not to release an backwards-incompatible Caml 4.0,
given there was a configure switch when building the compiler to build it
using a frozen 3.x library, which was not possible 3.9 -> 3.10.  After all,
incompatibilities are what major version numbers are for.

>From then on, the OCaml team could ship a language only tarball (plus
compatability library) and concentrate on exactly what they are good at:
writing a great implementation of OCaml, without us bugging them about
improving the library.  All of the package managers being discussed could
pull the language from INRIA and the "new" stdlib from wherever it is housed
and automagically put the two together.

--Jonathan

[...snip...]

[...(again)...]

[...(and again)...]

[...(yet again)...]

[-- Attachment #2: Type: text/html, Size: 3084 bytes --]

Re: [Caml-list] [OSR] Caml Community Code

[Vincent Hanquez]

On Fri, Feb 01, 2008 at 02:00:19PM -0500, Jonathan Bryant wrote:
>  I think that backwards-incompatibility, despite what INRIA may say, is not
> terribly important.  Let us not forget that they set a precedent when they
> released a incompatible and scantily documented, yet significantly improved,
> CamlP4 unannounced in 3.10.
> 
> I think that if the community wrote a new, significantly improved but
> incompatible standard library and handed it to INRIA, INRIA would be hard
> pressed to find a reason not to release an backwards-incompatible Caml 4.0,
> given there was a configure switch when building the compiler to build it
> using a frozen 3.x library, which was not possible 3.9 -> 3.10.  After all,
> incompatibilities are what major version numbers are for.
> 
> >From then on, the OCaml team could ship a language only tarball (plus
> compatability library) and concentrate on exactly what they are good at:
> writing a great implementation of OCaml, without us bugging them about
> improving the library.  All of the package managers being discussed could
> pull the language from INRIA and the "new" stdlib from wherever it is housed
> and automagically put the two together.

I just want to say that I really agree with this vision as well.
That's the only way this ocaml community thing is going to work IMHO.

-- 
Vincent Hanquez

Re: [Caml-list] [OSR] Caml Community Code

[Christopher L Conway]

On Feb 1, 2008 1:07 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Friday 01 February 2008 13:56:36 Christopher L Conway wrote:
> > Jon,
> >
> > So far as I can tell, there is exactly one person on this mailing list
> > who is interested in forking OCaml.
>
> We should clarify exactly what we mean by "forking OCaml".
>
> I get the impression that you are asking if I want to make a replica of
> INRIA's OCaml, diverge its evolution and steal as many existing OCaml users
> as possible.
>
> > So the relevant questions is: are *you* going to be forking OCaml?
>
> I want to improve OCaml and I am evaluating how this might be done. Forking is
> one possibility.
>
> One thing I would like to do is try to reconcile existing "OCaml-derived"
> distributions, taking the best from each of them. I am happy to call
> these "forks" but perhaps that has bad connurtations.

Yes, it does. My interpretation is as you have described above: to
create a separate, backwards- or forwards-incompatible version of the
core compiler without INRIA's cooperation. I think a "fork" under this
interpretation would be a mistake.

> I would like to encourage existing users to go public with their own forks so
> that we can reconcile them in order to build a single, newer, better,
> enhanced OCaml that everyone is free to share.
>
> Lots of other people are thinking along similar lines but I, for one, am not
> at all clear on who is doing what and, in particular, what exactly their
> goals are.

I agree: it is extremely unclear exactly where this "Community OCaml"
initiative is going to go. It seems probable that it will provide a
channel through which your suggestions for evolving the language can
be considered and potentially accepted into an official or
quasi-official release. Probably the most productive way you could
advance your concerns right now is to advocate for just such a
channel: some JSR-like arrangement that will bring INRIA into the loop
and allow the community to form a consensus around feature requests.

Perhaps no such arrangement will come to pass, or perhaps the
community will reject your proposals after a full and fair hearing. I
suggest that we wait and see before we resort to loose talk of forking
the code.

Best regards,
Chris

Re: [Caml-list] [OSR] Caml Community Code

[Jean-Marc EBER]

Hi all,

Without entering into a dialog on this list, LexiFi, whose name has been cited 
in this mail, wants to make the following clarification(s):

Jon Harrop a écrit :
> One thing I would like to do is try to reconcile existing "OCaml-derived" 
> distributions, taking the best from each of them. I am happy to call 
> these "forks" but perhaps that has bad connurtations.
> 
> For example, Alain Frisch recently said:
> 
>   "In particular, we have our locally-patched version of OCaml and all the 
> third-party libraries (either in source or binary form) in the repository."
> 
> To me, that means LexiFi forked OCaml for their own purposes. Many other 
> industrial users have also forked OCaml. More importantly, these forks are 
> often degenerate: they reimplement the same missing functionality, often in 
> slightly different and incompatible ways.
> 

[I cannot speak for "other industrial users" of course]

1. LexiFi is a member of the Caml Consortium. We think that anybody projecting
serious business with OCaml should try to become such a member.

2. LexiFi is not, in any way, "forking" OCaml. LexiFi is, however, producing and 
selling a "sectorial enhanced" (in our case for the financial sector) OCaml 
compiler. We are very careful in _not_ calling it OCaml, although we publish 
clearly our OCaml compatibility (which our clients are indeed calling for, let 
alone for being able to use the many existing OCaml documentations and libraries).

3. On a regular basis, we upgrade our compiler to the newest OCaml/Inria version.

4. Our "diff" with respect to OCaml that we want, in our own interest, to keep 
as small as possible, can be categorized in 3 kinds:

a. Sectorial enhancements: no interest for the OCaml community, as OCaml is 
supposed to be a general purpose language.

b. Other enhancements that are useful to ourselves or our customers, but that 
are only partially implemented, making any inclusion into OCaml (supposed that 
they would be accepted) impossible. A typical example is an extension of type 
declarations with some annotation mechanism that does not work well with 
objects, polymorphic variants or functors. Clearly a show stopper in OCaml, 
acceptable in a specialized setting like ours.

c. General purpose cleanups, small enhancements etc.: we inform Inria about 
them: Inria may or may not incorporate these patches.


To be clear: LexiFi will not support or participate in any OCaml activity or 
community project that is not clearly managed to go "hand in hand" with Inria.

> 
> . OCaml's top-level runs interpreted bytecode and, consequently, is many times 
> slower than the interactive sessions of "competing" language implementations 
> like SBCL (Lisp) and F#. Alain Frisch has already implemented a native-code 
> top-level for OCaml called "ocamlnat" in his "natdynlink" fork of OCaml. I 
> found this extremely useful and would like it to be easier for other people 
> to benefit from this work.

Jon, please, be careful with your public statements here.
The "natdynlink" branch (repeat after me, branch, _not_ fork) has been 
implemented by Alain Frisch when he was at Inria, with full knowledge of Xavier 
Leroy. The idea was that if this _branch_ worked, it was supposed to become 
mainstream; this is so true that it has been merged into... cvs HEAD !

Best regards,

Jean-Marc Eber
LexiFi

Re: [Caml-list] [OSR] Caml Community Code

[Jon Harrop]

On Monday 04 February 2008 14:35:01 Jean-Marc EBER wrote:
> Hi all,
>
> Without entering into a dialog on this list, LexiFi, whose name has been
> cited in this mail, wants to make the following clarification(s):

Thank you for clarifying.

> ...
> c. General purpose cleanups, small enhancements etc.: we inform Inria about
> them: Inria may or may not incorporate these patches.

This is exactly the work that I think we should be sharing and all benefitting 
from. I think everyone has reached an understanding on how beneficial this 
could be even if we disagree about how to achieve that goal.

> > . OCaml's top-level runs interpreted bytecode and, consequently, is many
> > times slower than the interactive sessions of "competing" language
> > implementations like SBCL (Lisp) and F#. Alain Frisch has already
> > implemented a native-code top-level for OCaml called "ocamlnat" in his
> > "natdynlink" fork of OCaml. I found this extremely useful and would like
> > it to be easier for other people to benefit from this work.
>
> Jon, please, be careful with your public statements here.
> The "natdynlink" branch (repeat after me, branch, _not_ fork) has been
> implemented by Alain Frisch when he was at Inria, with full knowledge of
> Xavier Leroy. The idea was that if this _branch_ worked, it was supposed to
> become mainstream; this is so true that it has been merged into... cvs HEAD
> !

Excellent! I was under the impression that ocamlnat was deleted in the merge 
but it appears to compile from the current CVS... :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] [OSR] Caml Community Code

[Ashish Agarwal]

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

> called Caml Community Code ... for community OCaml

Is the language called Caml or OCaml? It would be nice to agree on that.


2008/1/31 Jonathan Bryant <watersofmemory@gmail.com>:

> List,
>
> Despite all the great ideas on the [OSR] threads, we seem to be getting
> nowhere and talking ourselves to death bickering about implementation
> details of code that hasn't even been written yet.  I think the only thing
> we can agree on is that tools for use by the community should be written by
> the community.  Because of that, we need to start writing them: the best way
> to find out what works is to try.
>
> I've created a SourceForge project called Caml Community Code here (
> http://sourceforge.net/projects/camlcode) where we can put any code for
> community OCaml tools.  The fact that we can't hack the OCaml language
> itself (due to French copyright law) seems to have unfortunately caused the
> community to not hack together on other tools _for_ the language.  With this
> project everyone can hack on the tools we'll (hopefully) end up using every
> day, rather than having INRIA or one person try to build something that
> satisfies everyone.  If you have code for tools (I know someone at least has
> some code for a package manager), please put it in the repository so we can
> all see and work on it _as as community_.
>
> Regarding the package manager discussion, what we need is a few
> functioning prototypes.  Later we can go back and cherry pick features we
> like and merge them down to just two to develop a little more, and finally
> pick one.  I also think we should have one CamlP4 grammar with all the
> community's agreed upon "standard" syntax extensions (sort of a "new
> revised" syntax?), a set of "standard" ocamlbuild plugins, and "standard"
> interfaces (XML parser, etc.), all of which can be stored in the project as
> well.
>
> I was waiting for the project to get approved before sending this out (it
> just came through this morning), so I'll go ahead and make a temporary
> directory layout.
>
> --Jonathan
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

[-- Attachment #2: Type: text/html, Size: 3088 bytes --]

Re: [Caml-list] [OSR] Caml Community Code

[Jonathan Bryant]

[-- Attachment #1: Type: text/plain, Size: 279 bytes --]

2008/1/31 Ashish Agarwal <agarwal1975@gmail.com>:

> > called Caml Community Code ... for community OCaml
>
> Is the language called Caml or OCaml? It would be nice to agree on that.
>

Not that it's particularly relevant now, but I was going for the
alliteration...

--Jonathan

[-- Attachment #2: Type: text/html, Size: 557 bytes --]

RE: [Caml-list] [OSR] Caml Community Code

[David Allsopp]

> I also think we should have one CamlP4 grammar with all the community's
> agreed upon "standard" syntax extensions (sort of a "new revised"
> syntax?)

Am I correct in thinking that you can only use one camlp4 parser per source
file - i.e. that parsers cannot be automatically composed, even if that is
logically (grammatically) possible?


David

Re: [Caml-list] [OSR] Caml Community Code

[Jonathan Bryant]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

On Fri, Feb 1, 2008 at 12:26 PM, David Allsopp <dra-news@metastack.com>
wrote:

> > I also think we should have one CamlP4 grammar with all the community's
> > agreed upon "standard" syntax extensions (sort of a "new revised"
> > syntax?)
>
> Am I correct in thinking that you can only use one camlp4 parser per
> source
> file - i.e. that parsers cannot be automatically composed, even if that is
> logically (grammatically) possible?


I believe multiple CamlP4 parsers can be specified on the command line and
are used in the order given.  But there are a few (relatively trivial)
syntax extensions people are commonly asking for (try ... finally is
probably the most common), so I was suggesting that we group the most
requested ones into a single camlp4 rather than users having to keep up with
and constantly specify multiple camlp4s.

--Jonathan


>
>
> David
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 2043 bytes --]

Re: [Caml-list] [OSR] Caml Community Code

[Jon Harrop]

On Friday 01 February 2008 18:27:48 Jonathan Bryant wrote:
> I believe multiple CamlP4 parsers can be specified on the command line and
> are used in the order given.  But there are a few (relatively trivial)
> syntax extensions people are commonly asking for (try ... finally is
> probably the most common), so I was suggesting that we group the most
> requested ones into a single camlp4 rather than users having to keep up
> with and constantly specify multiple camlp4s.

Excellent idea.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] [OSR] Caml Community Code

[David Teller]

I confirm that you can chain several preprocessors. That's what I'm
doing to achieve pattern-matching on lazy lists.

Cheers,
 David

On Fri, 2008-02-01 at 18:25 +0000, Jon Harrop wrote:
> On Friday 01 February 2008 18:27:48 Jonathan Bryant wrote:
> > I believe multiple CamlP4 parsers can be specified on the command line and
> > are used in the order given.  But there are a few (relatively trivial)
> > syntax extensions people are commonly asking for (try ... finally is
> > probably the most common), so I was suggesting that we group the most
> > requested ones into a single camlp4 rather than users having to keep up
> > with and constantly specify multiple camlp4s.
> 
> Excellent idea.
> 
-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

[OSR] Caml Community Code

[Jonathan Bryant]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

List,

Despite all the great ideas on the [OSR] threads, we seem to be getting
nowhere and talking ourselves to death bickering about implementation
details of code that hasn't even been written yet.  I think the only thing
we can agree on is that tools for use by the community should be written by
the community.  Because of that, we need to start writing them: the best way
to find out what works is to try.

I've created a SourceForge project called Caml Community Code here (
http://sourceforge.net/projects/camlcode) where we can put any code for
community OCaml tools.  The fact that we can't hack the OCaml language
itself (due to French copyright law) seems to have unfortunately caused the
community to not hack together on other tools _for_ the language.  With this
project everyone can hack on the tools we'll (hopefully) end up using every
day, rather than having INRIA or one person try to build something that
satisfies everyone.  If you have code for tools (I know someone at least has
some code for a package manager), please put it in the repository so we can
all see and work on it _as as community_.

Regarding the package manager discussion, what we need is a few functioning
prototypes.  Later we can go back and cherry pick features we like and merge
them down to just two to develop a little more, and finally pick one.  I
also think we should have one CamlP4 grammar with all the community's agreed
upon "standard" syntax extensions (sort of a "new revised" syntax?), a set
of "standard" ocamlbuild plugins, and "standard" interfaces (XML parser,
etc.), all of which can be stored in the project as well.

I was waiting for the project to get approved before sending this out (it
just came through this morning), so I'll go ahead and make a temporary
directory layout.

--Jonathan

[-- Attachment #2: Type: text/html, Size: 2045 bytes --]

Re: [Caml-list] [OSR] Caml Community Code

[Romain Beauxis]

Le Thursday 31 January 2008 16:57:24 Jonathan Bryant, vous avez écrit :
> List,

	Hi !

> Despite all the great ideas on the [OSR] threads, we seem to be getting
> nowhere and talking ourselves to death bickering about implementation
> details of code that hasn't even been written yet.  I think the only thing
> we can agree on is that tools for use by the community should be written by
> the community.  Because of that, we need to start writing them: the best
> way to find out what works is to try.
>
> I've created a SourceForge project called Caml Community Code here (
> http://sourceforge.net/projects/camlcode) where we can put any code for
> community OCaml tools.  The fact that we can't hack the OCaml language
> itself (due to French copyright law) seems to have unfortunately caused the
> community to not hack together on other tools _for_ the language.  With
> this project everyone can hack on the tools we'll (hopefully) end up using
> every day, rather than having INRIA or one person try to build something
> that satisfies everyone.  If you have code for tools (I know someone at
> least has some code for a package manager), please put it in the repository
> so we can all see and work on it _as as community_.

It's a good idea, but it seems a duplicate of the ocamlcore.org on-going 
server announced by Sylvain..

So rather than creating another instance, it should be better to join efforts 
together, don't you think ?


Romain

Re: [Caml-list] [OSR] Caml Community Code

[Jonathan Bryant]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Thu, Jan 31, 2008 at 11:08 AM, Romain Beauxis <toots@rastageeks.org>
wrote:

> Le Thursday 31 January 2008 16:57:24 Jonathan Bryant, vous avez écrit :


[...]


>
> It's a good idea, but it seems a duplicate of the ocamlcore.org on-going
> server announced by Sylvain..


>
> So rather than creating another instance, it should be better to join
> efforts
> together, don't you think ?
>

I did not see that message in the midst of that thread.  On the one hand, I
don't want to duplicate efforts.  On the other, SourceForge has a host of
development resources available, plus builtin user management, etc.  It
would be nice to have our own site, but there doesn't seem to be much at all
up yet.  I'd be in favor of having something that's working _now_ as opposed
to something that's going the be amazing ... in a few months ... whenever we
get it up ...

Sylvan, what are your thoughts?  The last thing I want is two "competing"
sites...

--Jonathan

[-- Attachment #2: Type: text/html, Size: 1693 bytes --]