ocaml-lib-devel

[Ocaml-lib-devel] Goals & Process

[Nicolas C. <war...@fr...>]

Hi -new- list !

First of all, I think we should try not to talk about COAN or something like
that right now. Why ? Because the discussion has still to go on on the main
OCaml mailling list, and such idea has already been raised a few time, but
no global agreement was found amoung the community. And also, because I
would like to wait what for example Maxence Gesdon, the OCaml Hump author,
is thinking about it.

So, my first proposal about the goals is that this list be dedicaced only
( rigth now ) to the ExtLib project.

Personal comments about what have been discussed on the mailing list :

- about the license, I don't really care if it's LGPL or not, but as I
already suggest, I think that being "free for any use" would be better

- about how to process , I agree with the "separate CVS branches and then
vote for commiting" style of running the project. Could you Amit please
setup the CVS so that each user can I its own directory with write access
( and read for the others ) as well as an "extlib" directory only writable
by administrators ?

Few rules I think we should follow :

- the ExtLib ( or any other name if you don't like this one :) has to remain
100% OCaml code ( no C part ! )
- any ExtLib part should match at least of of theses properties :
    ( from JMSkaller speaking about the C++Boost Library )
    * it provide important functionnality which is hard (or take time) for
the client to code up correctly [ important is the keyword ]
    * it provide a simple convenience which can be heavily used in any kind
of application [ simple and heavily are the keyword ]
    * (adding this one) it provide standardized access to a commonly used
data structure [ standardized is the keyword ]
- since right now the inclusion of bytecode in a binary is file-based, the
ExtLib has to be split in several files to keep the users binaries small

How to process :

- each developper develops its own branch of the ExtLib
- once a developper has a branch ready, he have to ask for peer review /
comments from the ExtLib developper community
- if the community reach an agreement on branch committing, the branch is
added to the ExtLib
- if the community don't reach an agreement, it's in the end ExtLib
administrators ( no more than 3 or 4 people ) who are deciding to add it or
not
- if the community mostly disagree, the branch is not committed, and
administrators don't have to settle
- once a branch is committed, its maintainer is no longer the original
developper, but the whole ExtLib community
- ExtLib bug fixes are addressed directly to the administrators which can
either patch the ExtLib or classify it as "not a bug"
- ExtLib existing branch improvement/addons use the same process as
committing

All theses are proposals, if the current people here ( who's in there ? :)
agree then it would be nice to put theses rules somewhere in the ExtLib
FAQ/Rules.

Nicolas Cannasse

Re: [Ocaml-lib-devel] Goals & Process

[Maxence G. <max...@in...>]

Hi,
=20
> First of all, I think we should try not to talk about COAN or something l=
ike
> that right now. Why ? Because the discussion has still to go on on the ma=
in
> OCaml mailling list, and such idea has already been raised a few time, but
> no global agreement was found amoung the community. And also, because I
> would like to wait what for example Maxence Gesdon, the OCaml Hump author,
> is thinking about it.

Well, the humps are basically just lists of=20
- applications, which can be seen as code examples and proofs that OCaml is=
 a
real-world language,
- libraries to reuse
- and docs to learn and make better use of the language.

There is no concept of installation nor dependencies in these lists. I woul=
d say
it's degree 0 of a code repository.

From the experience of Fabrice Le Fessant and Alan Schmitt (and others) in =
the
CDK, putting together libraries is a nightmare : different makefiles styles,
compilation procedures, ...

So before thinking about COAN, the important point is to define *standards*=
 for
OCaml documentation, compilation and installation :
- documentation : ocamldoc can help
- compilation : various os must be taken into account
(Linux/Unix/Window$/MacOS), byte and native code generation,
- installation : I agree that ocamlfind would help on this. A fetch
functionality would be needed too, =E0 la debian apt-get.

Once this is defined, then we can think about COAN, but not before. So I ag=
ree
with Nicolas.

> Few rules I think we should follow :
>=20
> - the ExtLib ( or any other name if you don't like this one :) has to rem=
ain
> 100% OCaml code ( no C part ! )
> - any ExtLib part should match at least of of theses properties :
>     ( from JMSkaller speaking about the C++Boost Library )
>     * it provide important functionnality which is hard (or take time) for
> the client to code up correctly [ important is the keyword ]
>     * it provide a simple convenience which can be heavily used in any ki=
nd
> of application [ simple and heavily are the keyword ]
>     * (adding this one) it provide standardized access to a commonly used
> data structure [ standardized is the keyword ]
> - since right now the inclusion of bytecode in a binary is file-based, the
> ExtLib has to be split in several files to keep the users binaries small

Agreed.
=20
> How to process :
>=20
> - each developper develops its own branch of the ExtLib
> - once a developper has a branch ready, he have to ask for peer review /
> comments from the ExtLib developper community
> - if the community reach an agreement on branch committing, the branch is
> added to the ExtLib
> - if the community don't reach an agreement, it's in the end ExtLib
> administrators ( no more than 3 or 4 people ) who are deciding to add it =
or
> not
> - if the community mostly disagree, the branch is not committed, and
> administrators don't have to settle
> - once a branch is committed, its maintainer is no longer the original
> developper, but the whole ExtLib community
> - ExtLib bug fixes are addressed directly to the administrators which can
> either patch the ExtLib or classify it as "not a bug"
> - ExtLib existing branch improvement/addons use the same process as
> committing
>=20
> All theses are proposals, if the current people here ( who's in there ? :)
> agree then it would be nice to put theses rules somewhere in the ExtLib
> FAQ/Rules.

Hum, this does not prevent various developpers to code the same functions, =
and
the admins will still have to choose among hundreds. If they aren't afraid,=
 we
can do that, but I still think a discussion about what's needed would save =
time.
I agree this kind of discussion can be messy, but by giving the types of the
functions and a comment =E0 la ocamldoc, an agreement could be reached quic=
kly.

--=20
Maxence Guesdon
=20

Re: [Ocaml-lib-devel] Goals & Process

[fva <fv...@ts...>]

By way of informal vote on the proposal by other people...

Maxence Guesdon wrote:

>So before thinking about COAN, the important point is to define *standards* for
>OCaml documentation, compilation and installation :
>- documentation : ocamldoc can help
>
Agreed

>- compilation : various os must be taken into account
>(Linux/Unix/Window$/MacOS), byte and native code generation,
>
Agreed, if not taken to mean "every contributor will make sure that 
his/her code runs on all platforms", only on the spirit of the project.

>- installation : I agree that ocamlfind would help on this.
>
Agreed.

>A fetch
>functionality would be needed too, à la debian apt-get.
>
Agreed.

>Once this is defined, then we can think about COAN, but not before. So I agree
>with Nicolas.
>
Agreed.

>>Few rules I think we should follow :
>>
>>- the ExtLib ( or any other name if you don't like this one :) has to remain
>>100% OCaml code ( no C part ! )
>>
???? Don't have a strong opinion. Wouldn't object to good wrappers it 
OCaml code was not available. Better see it well documented and filtered 
through signatures than not see it at all.

>>- any ExtLib part should match at least of of theses properties :
>>    ( from JMSkaller speaking about the C++Boost Library )
>>    * it provide important functionnality which is hard (or take time) for
>>the client to code up correctly [ important is the keyword ]
>>
Agreed

>>    * it provide a simple convenience which can be heavily used in any kind
>>of application [ simple and heavily are the keyword ]
>>
Agreed

>>    * (adding this one) it provide standardized access to a commonly used
>>data structure [ standardized is the keyword ]
>>
Agreed (Hard, this one!)

>>- since right now the inclusion of bytecode in a binary is file-based, the
>>ExtLib has to be split in several files to keep the users binaries small
>>
Agreed. (A writing a single structure/functor in each file?).

>
>Agreed.
>

>>How to process :
>>
>>- each developper develops its own branch of the ExtLib
>>- once a developper has a branch ready, he have to ask for peer review /
>>comments from the ExtLib developper community
>>- if the community reach an agreement on branch committing, the branch is
>>added to the ExtLib
>>- if the community don't reach an agreement, it's in the end ExtLib
>>administrators ( no more than 3 or 4 people ) who are deciding to add it or
>>not
>>- if the community mostly disagree, the branch is not committed, and
>>administrators don't have to settle
>>- once a branch is committed, its maintainer is no longer the original
>>developper, but the whole ExtLib community
>>- ExtLib bug fixes are addressed directly to the administrators which can
>>either patch the ExtLib or classify it as "not a bug"
>>- ExtLib existing branch improvement/addons use the same process as
>>committing
>>
Agreed to everything (but would think twice about opting for 
administrator of the library in this conditions).

>>All theses are proposals, if the current people here ( who's in there ? :)
>>agree then it would be nice to put theses rules somewhere in the ExtLib
>>FAQ/Rules.
>>    
>>
>
>Hum, this does not prevent various developpers to code the same functions, and
>the admins will still have to choose among hundreds. If they aren't afraid, we
>can do that, but I still think a discussion about what's needed would save time.
>I agree this kind of discussion can be messy, but by giving the types of the
>functions and a comment à la ocamldoc, an agreement could be reached quickly.
>
Let contributions be made on a signature or structure basis... Let 
people meet and present whole signatures and structures instead of just 
functions. Or at least encourage them to... (I am aware that some 
functions just do not belong in a (single?) signature).

Regards,

        Fran Valverde

>
>  
>

Re: [Ocaml-lib-devel] Goals & Process

[John M. S. <sk...@oz...>]

>=20
> Hum, this does not prevent various developpers to code the same functio=
ns, and
> the admins will still have to choose among hundreds.=20


I think you are very hopeful :-)

>If they aren't afraid, we
> can do that, but I still think a discussion about what's needed would s=
ave time.


> I agree this kind of discussion can be messy, but by giving the types o=
f the
> functions and a comment =E0 la ocamldoc, an agreement could be reached =
quickly.

A person suggesting an extension should write a proposal and
see the reaction to it before proceeding. Although this process is
slower than just doing it, some discussion is valuable.

As a matter of interest: the *principle* driving force
behing core language changes in the C++ language in the latter
time before standardisation was needs exposed by the library
working group.

In reverse: a consistent set of library
facilities should often model a missing core language combinator.

For example map, iter, fold, count should be combinators, but the
core language isn't strong enough to support that so they're
a collection of library functions instead.
I myself miss 'count' on hashtables.

--=20
John Max Skaller, mailto:sk...@oz...
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850