ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] Ocaml indent?

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

>> For that, we already have a decomposition to follow, that of the
>> standard library itself.  We need a name, a license, a compilation
>> strategy, and an installation strategy.

I think we should be careful here. In my opinion Boost went entirely

off the rails by chosing a special make tool, and then modifying
that so that to actually build boost became a total nightmare.

They failed to follow my recommendation:-)

I recommended Python script as the build tool, and they
thought it was 'too heavy' which of course turned out
to be a joke compared to having to download and build
a custom tool -- which needed constant modification.

I personally DESPISE make and friends, I think they're
total garbage. While they automate some tasks nicely,
trying to fool make into doing all the build/test/install
tasks correctly requires considerably expertise and hackery.

Python, on the other hand, is a full scale programming language.

Well, we should probably use ocaml script instead :-)




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

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

[Ocaml-lib-devel] Ocaml Libs

[Brian H. <bri...@ql...>]

More comments comming soon.

I have 2.5 libraries I've written I'd like to see included.  They (and 
their status) are:

- Psqueue, implementing a Priority Search Queue ala:
http://www.informatik.uni-bonn.de/~ralf/talks/ICFP01.pdf
This data structure has the best features of both a priority queue (O(1) 
find the highest priority element, O(log n) remove the highest priority 
element) and search trees (O(log n) to add, find, modify the priority of, 
or remove any element).  It is purely applicative.  It is commented, 
cleaned up, and forgotten at home at the moment.

- Bitset, implementing an unordered set of unique small integers as a 
bitfield.  Adding or removing and element and checking to see if an 
element is contained in the set are all O(1).  It is imperitive in style.  
I need to add a couple of functions (just remembered I forgot union and 
intersection) and commenting and it'll be ready to go.

- Regex, a regular expressions library.  This is the .5- it's about half 
written at this point.

Brian

Re: [Ocaml-lib-devel] Re: [Caml-list] OCaml standard library improvement

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

> If what Zacchiroli is true (read the news article) we may be in for a
> disappointment being hosted in SourceForge... Can anybody give further
> news about this claim of relinquishing our rights & work for the benefit
> of SourceForge if we are hosted with them?

Are VA Linux people using OCaml ? If they're then yes perhaps they'll be
able to use the ExtLib for any use. I don't see any problem with it. BTW,
don't get paranoid , who will notice a small group of people working on a
small library for an obscure programming language ( developped by french
people :) ?

Nicolas Cannasse

Re: [Ocaml-lib-devel] Ocaml indent?

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

> > How about scribbling specs for libraries in module signatures then
> > producing structures that implement the signatures? In this way:
> > ...
> > libraries nowadays only because it's my own and I remember coding it
> > (and the names of the addons)).
>
> Sound good to me. To verify the signatures are the ones needed, each
person
> could look at his code and see if it would be what he wanted. What a pity
when
> the type of a function (for example the order of arguments) is *almost*
what we
> need and we have to create a dummy function, for example to change the
order of
> the arguments...

... or update your whole code using the ExtLib :)
Do it once, and sleep better after.

> BTW, what about labels ? with or without ? I vote for only optional
labels,
> except for functions with plenty of arguments of the same type.

Labels should be used for what they have been made for : tipping an ambigous
argument.
Of course optionals options are also welcome, but only if they're meeting a
massive need ( I wouldn't like to see ten optionals options for
some -can-do-everything- function )

Nicolas Cannasse

Re: [Ocaml-lib-devel] Ocaml indent?

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

> - the question of the consistency for the functions of a module is
> somewhat ameliorated because structures would claim to implement this or
> that signature only (I know: the problem would somehow be moved to
> designing the module's signature. Still, we'd be doing one problem at a
> time: what goes in, first, then how to build it...)

Agreed,
Talking first about the signatures is meaningful

> - the community could proffer several implementations for different
> signatures... This could mean competition between implementations
> (hopefully) for the benefit of everybody... (Also, some stabilisation of
> the (winning) modules in the library).

Yes, somehow
Several implementations should be discussed before committing, that's part
of the approval process.
An implementation can be changed latter if a better one is found or a bug
fixed, but the specification won't change

> - it could be demanded that people contributing to a *particular
> structure* follow the indentation mode of *that* structure... Besides If
> someone produced code and submitted it without the proper indentation,
> just indenting *one* structure in a coherent way is pretty easy for
> anybody to do. (We could see other people's practice and improve our
> "indenting" habits that way too!)

I don't think we should talk about indentation right now but well... Let's
do it.
There IS indentation rules in OCaml , they're used in the OCaml Sources and
specified somewhere ( in the Manual ? or any pointer ? )

> So what I propose is:
> - let's make a big library, the Extended Library, EL
> - made of a thousand smaller (smallish) modules and let people
> contribute to it.
> - implementing public (voted, agreed upon) signatures
> - that
>         a) extend signatures and modules of the standard library SL
>         b) provide different implementations to those of the SL (and
> test them, that's my dream)
>         c) provides *other* signatures and modules that hugely add
> functionality to the SL
>         d) make open "call-for-implementation"'s in the form of
>  signatures interesting to the community.
>         e)...

That make sense
But I don't agree with the "thousand".
The current goal is not to put every existing (although very used) ocaml
library into the ExtLib. For example PXP, which is a very good XML parser -
and everybody is using XML in today applications - should remain a separate
library. The ExtLib should remain somehow small :)

Nicolas Cannasse

[Ocaml-lib-devel] Re: [Caml-list] OCaml standard library improvement

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

If what Zacchiroli is true (read the news article) we may be in for a 
disappointment being hosted in SourceForge... Can anybody give further 
news about this claim of relinquishing our rights & work for the benefit 
of SourceForge if we are hosted with them?

Regards,

        Fran Valverde

Stefano Zacchiroli wrote:

>On Sun, Feb 23, 2003 at 08:46:01PM -0600, Brian Hurt wrote:
>  
>
>>In the interest of getting a move on, if I don't hear any complaints
>>in the next day or two, I'll start the project unilaterally.
>>    
>>
>
>If you really want to go this way please consider using savannah instead
>of sourceforge:
>
>  http://savannah.gnu.org/
>  http://www.fsfeurope.org/news/article2001-10-20-01.en.html
>
>BTW even if this wasn't my original idea I will obviously happy to join
>the project and share some code.
>
>Cheers
>
>  
>

Re: [Ocaml-lib-devel] Ocaml indent?

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

Again voting on somebody else's proposals...

Manos Renieris wrote:

>On Mon, Feb 24, 2003 at 10:34:07PM +0100, Maxence Guesdon wrote:   
>It seems to me that the priority is the shadow of the standard library.
>
Agreed.

>For that, we already have a decomposition to follow, that of the
>standard library itself.  We need a name, a license, a compilation
>strategy, and an installation strategy.
>
>For the name, somebody mentioned ExtLib. 
>
Agreed.

>For the license, the argument
>has been made that we would be extending the standard library, and it
>would be much simpler to keep its license.  
>
Agreed.

>The obvious choices for the 
>latter two are OCamlMakefile and findlib.
>
Agreed for both (but taken note of the problems with people in Windows & 
their tools).

Regards,

        Francisco Valverde

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] Ocaml indent?

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

> How about scribbling specs for libraries in module signatures then 
> producing structures that implement the signatures? In this way:
> ...
> libraries nowadays only because it's my own and I remember coding it 
> (and the names of the addons)).

Sound good to me. To verify the signatures are the ones needed, each person
could look at his code and see if it would be what he wanted. What a pity when
the type of a function (for example the order of arguments) is *almost* what we
need and we have to create a dummy function, for example to change the order of
the arguments...

BTW, what about labels ? with or without ? I vote for only optional labels,
except for functions with plenty of arguments of the same type.

> - it could be demanded that people contributing to a *particular 
> structure* follow the indentation mode of *that* structure... Besides If 
> someone produced code and submitted it without the proper indentation, 
> just indenting *one* structure in a coherent way is pretty easy for 
> anybody to do. (We could see other people's practice and improve our 
> "indenting" habits that way too!)

Agreed.

-- 
Maxence Guesdon

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] Ocaml indent?

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

Maxence Guesdon wrote:

>>Make some incredibly minimum directory layout suggestions and minimal 
>>project documentation (something like text file called "description.txt" in 
>>the root of each module).  Then get a ton of code up there.  Deal with the 
>>consequences later.  The number of community projects with intricate and 
>>beautiful submission specifications and no useful code or users far 
>>outweighs the number of useful projects bogged down by bad indentation and 
>>planning.
>>    
>>
>
>I don't think uploading a ton of code and deal with consequences *later* is the easy way : someone will have to sort the functions, and try to give some consistency for the functions of a module. This can be very difficult when it means finding the good functions among hundreds.
>
>What about this other way : let's find some topics for modules (strings, lists, ...), then for each topic ask everyone what functions are missing and useful, then upload them or code them. Otherwise, I'm afraid the mess in the libraries will result in mess in programs using them.
>
>Building stable libraries will make them more usable : I don't think anyone would use a library whose interface is always changing.
>
How about scribbling specs for libraries in module signatures then 
producing structures that implement the signatures? In this way:

- the question of the consistency for the functions of a module is 
somewhat ameliorated because structures would claim to implement this or 
that signature only (I know: the problem would somehow be moved to 
designing the module's signature. Still, we'd be doing one problem at a 
time: what goes in, first, then how to build it...)

- the community could proffer several implementations for different 
signatures... This could mean competition between implementations 
(hopefully) for the benefit of everybody... (Also, some stabilisation of 
the (winning) modules in the library).

- signatures *to some extent* can be extended (as structure 
implementations can)... The library could well be extended bit by bit, 
but always having a "usable" form. I once extended the OCaml string 
library using some primitives that I lacked from CAML and it was pretty 
usable (I've been using it ever since although I see better string 
libraries nowadays only because it's my own and I remember coding it 
(and the names of the addons)).

- it could be demanded that people contributing to a *particular 
structure* follow the indentation mode of *that* structure... Besides If 
someone produced code and submitted it without the proper indentation, 
just indenting *one* structure in a coherent way is pretty easy for 
anybody to do. (We could see other people's practice and improve our 
"indenting" habits that way too!)

In a word, let's profit by the capability of the language for developing 
code piecewise and with "local" flavours but in a public "milieu" where 
everybody knows what they should do even if their guts remain 
(hopefully, neatly)  hidden.

So what I propose is:
- let's make a big library, the Extended Library, EL
- made of a thousand smaller (smallish) modules and let people 
contribute to it.
- implementing public (voted, agreed upon) signatures
- that
        a) extend signatures and modules of the standard library SL
        b) provide different implementations to those of the SL (and 
test them, that's my dream)
        c) provides *other* signatures and modules that hugely add 
functionality to the SL
        d) make open "call-for-implementation"'s in the form of 
 signatures interesting to the community.
        e)...

When we have a high population of signatures and implementations, we'll 
start thinking about good retrieval mechanisms with them (something that 
rubs off when you're doing experimentation: first you need a BIG corpus 
of real data, then you try to extract structure from it). There's a 
number of them hovering already...

Regards,

        Fran Valverde

[Ocaml-lib-devel] test email

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

hi all

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

Re: [Ocaml-lib-devel] Ocaml indent?

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

> It seems to me that the priority is the shadow of the standard library.
> For that, we already have a decomposition to follow, that of the
> standard library itself.  We need a name, a license, a compilation
> strategy, and an installation strategy

True,
I agree to concentrate first on ExtLib and then later discuss about the
OCaml web librairies repository

> For the name, somebody mentioned ExtLib. For the license, the argument
> has been made that we would be extending the standard library, and it
> would be much simpler to keep its license.  The obvious choices for the
> latter two are OCamlMakefile and findlib.

I'm one of the few Windows OCaml users, and findlib nor OCamlMake aren't
available on this platform. I wrote a tool sometime ago called "ocamake"
which is doing I think the same as OCamlMake.

It's a command line tool that take several ml / mli ( and others ) files =
as
input, call ocamldep and then compile the whole using ocamlc or ocamlopt.=
 It
has also an option to generate a Makefile that can be used as input for
either GNU Make or Microsoft NMAKE ( no more use of two separate Makefile
and Makefile.nt ).

I would of course be more than happy if the ExtLib community would like t=
o
use this tool as a standard. It has been roughly tested and the full OCam=
l
sourcefile is available at  http://tech.motion-twin.com . BTW, it only us=
e
the Unix OCaml library and don't rely on any non standard library.

Perhaps I could add an XML input that well enable it to load xml project
descriptors =E0 la Ant. What do you think about it ?

> To proceed, I suppose we could all upload our proposals for extensions =
to
> the StdLib modules, and vote about the appropriateness of each one.
> (I have no experience with distributed development, so I have no idea
> about the actual workings of this, but the Boost's guidelines can serve
> a starting point.)

Please read the proposal rules I've been writting in the "Goals & Process=
"
thread.

Nicolas Cannasse

Re: [Ocaml-lib-devel] Ocaml indent?

[Manos R. <er...@cs...>]

On Mon, Feb 24, 2003 at 10:34:07PM +0100, Maxence Guesdon wrote:
> > Make some incredibly minimum directory layout suggestions and minimal 
> > project documentation (something like text file called "description.txt" in 
> > the root of each module).  Then get a ton of code up there.  Deal with the 
> > consequences later.  The number of community projects with intricate and 
> > beautiful submission specifications and no useful code or users far 
> > outweighs the number of useful projects bogged down by bad indentation and 
> > planning.
> 
> I don't think uploading a ton of code and deal with consequences
> *later* is the easy way : someone will have to sort the functions, and
> try to give some consistency for the functions of a module. This can
> be very difficult when it means finding the good functions among
> hundreds.
> 
> What about this other way : let's find some topics for modules
> (strings, lists, ...), then for each topic ask everyone what functions
> are missing and useful, then upload them or code them. Otherwise, I'm
> afraid the mess in the libraries will result in mess in programs using
> them.

A lot of ideas for different projects have been going around. It seems
different people are looking for
a) a shadow of the standard library, with extensions, such as
   tail-recursive versions of all the List functions (where it's possible).
b) a general repository of libraries, like the Humps, but including 
   code in library form (as opposed to finished programs), and actually
   storing the code (as opposed to just pointing to it, as in the
   humps).
c) An shared project to develop new libraries for Ocaml, as the need
   rises.
   
It seems to me that the priority is the shadow of the standard library.
For that, we already have a decomposition to follow, that of the
standard library itself.  We need a name, a license, a compilation
strategy, and an installation strategy.

For the name, somebody mentioned ExtLib. For the license, the argument
has been made that we would be extending the standard library, and it
would be much simpler to keep its license.  The obvious choices for the 
latter two are OCamlMakefile and findlib.

To proceed, I suppose we could all upload our proposals for extensions to
the StdLib modules, and vote about the appropriateness of each one.
(I have no experience with distributed development, so I have no idea
about the actual workings of this, but the Boost's guidelines can serve
a starting point.)

-- Manos

[Ocaml-lib-devel] Module addons (was : Ocaml indent?)

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

 > Make some incredibly minimum directory layout suggestions and minimal
 > project documentation (something like text file called "description.txt"
in
 > the root of each module).  Then get a ton of code up there.  Deal with
the
>> consequences later.  The number of community projects with intricate and
 >> beautiful submission specifications and no useful code or users far
 >> outweighs the number of useful projects bogged down by bad indentation
and
 >> planning.
 >
 > I don't think uploading a ton of code and deal with consequences *later*
is the easy way :
> someone will have to sort the functions, and try to give some consistency
for the functions
> of a module. This can be very difficult when it means finding the good
functions among
> hundreds.
>
>  What about this other way : let's find some topics for modules (strings,
lists, ...), then
> for each topic ask everyone what functions are missing and useful, then
upload them or code
> them. Otherwise, I'm afraid the mess in the libraries will result in mess
in programs using
> them.
>
 > Building stable libraries will make them more usable : I don't think
anyone would use a
> library whose interface is always changing.

I totally agree with you Maxence, as I suggested in the "how to process"
part of my last mail.
But it's true right now lots of people have already been writing their own
librairies, so there is already code around. And I'm afraid that discussions
such as "what to include in such module" will be a big mess :) But let's try
:)

As for myself, my -own- library is adding several functions to the String
module - no function for the List module - and a whole new module called
MList , which is a mutable List with in-place add / remove etc...
About String, theses are mainly :

val split : string -> ~separator:string -> string * string  (* raise
Not_found *)
split "abcde" "c" => ("ab" , "de")

val lchop : string -> string
lchop "abcde" => "bcde"

val rchop : string -> string
rchop "abcde" => "abcd"

and also some usefull "C-like" shortcuts such as

let itos = string_of_int
let ftos = string_of_float

Nicolas Cannasse

[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] Ocaml indent?

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

> Make some incredibly minimum directory layout suggestions and minimal 
> project documentation (something like text file called "description.txt" in 
> the root of each module).  Then get a ton of code up there.  Deal with the 
> consequences later.  The number of community projects with intricate and 
> beautiful submission specifications and no useful code or users far 
> outweighs the number of useful projects bogged down by bad indentation and 
> planning.

I don't think uploading a ton of code and deal with consequences *later* is the easy way : someone will have to sort the functions, and try to give some consistency for the functions of a module. This can be very difficult when it means finding the good functions among hundreds.

What about this other way : let's find some topics for modules (strings, lists, ...), then for each topic ask everyone what functions are missing and useful, then upload them or code them. Otherwise, I'm afraid the mess in the libraries will result in mess in programs using them.

Building stable libraries will make them more usable : I don't think anyone would use a library whose interface is always changing.

-- 
Maxence Guesdon1

[Ocaml-lib-devel] Jungerl

[Brian H. <bri...@ql...>]

Just FYI:
http://www.bluetail.com/wiki/showPage?node=Jungerl

Brian

Re: [Ocaml-lib-devel] Ocaml indent?

[Chris H. <ch...@d6...>]

Please don't let this go the way of most community projects and get bogged 
down in indentation style and other meta issues.

Make some incredibly minimum directory layout suggestions and minimal 
project documentation (something like text file called "description.txt" in 
the root of each module).  Then get a ton of code up there.  Deal with the 
consequences later.  The number of community projects with intricate and 
beautiful submission specifications and no useful code or users far 
outweighs the number of useful projects bogged down by bad indentation and 
planning.

Chris

Re: [Ocaml-lib-devel] Ocaml indent?

[Brian H. <bri...@ql...>]

On Mon, 24 Feb 2003, Blair Zajac wrote:

> Brian Hurt wrote:
> I think in general this is a bad idea.  I would not want my code reindented
> upon commit.

I'm not that religous about indenting :-).  And I've dealt with formatting 
diasters- including one file that had been editted by three different 
people, in three different editors, using both unix and windows style 
tabbing, different indent levels, and different tab stops.  Which made me 
appreciate enforced standard indenting.

> 
> Also, this seems to mix style with real coding changes.  Many times, I
> perform two separate commits to make code reviews easier, one for
> coding changes, and one for style changes.
> 

Yep.  Nothing is more horrifying than seeing a log message that reads 
"fixed indenting, and a couple of bugs".  Because you know that the 
reindenting touched almost every single line of code, making diffs nigh on 
to impossible, and hiding what the real changes are.  Been there, done 
that too.

Brian

Re: [Ocaml-lib-devel] Ocaml indent?

[Blair Z. <bl...@or...>]

Brian Hurt wrote:
> 
> Something just occurred to me.  CVS has the ability to run a script on
> commits- explicitly, this is so you can run indent on code being
> committed.  For those who don't know, indent is a program which
> (re-)indents C code.  Allowing you to enforce convention like "no tabs",
> "curly braces on their own lines", etc.
> 
> If something like this existed for Ocaml, we could use to force indenting
> rules (once they are settled on).

I think in general this is a bad idea.  I would not want my code reindented
upon commit.

If there are commits that have poor coding style, then those could be pointed
out by the other developers and fixed in subsequent commits.

Also, this seems to mix style with real coding changes.  Many times, I perform
two separate commits to make code reviews easier, one for coding changes, and
one for style changes.

Best,
Blair

-- 
Blair Zajac <bl...@or...>
Plots of your system's performance - http://www.orcaware.com/orca/

Re: [Ocaml-lib-devel] Ocaml indent?

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

 
> Something just occurred to me.  CVS has the ability to run a script on 
> commits- explicitly, this is so you can run indent on code being 
> committed.  For those who don't know, indent is a program which 
> (re-)indents C code.  Allowing you to enforce convention like "no tabs", 
> "curly braces on their own lines", etc.
> 
> If something like this existed for Ocaml, we could use to force indenting 
> rules (once they are settled on).

Camlp4 could be used for this, but it loses comments in phrases :-(
If we want to put only comments between phrases, it could be what's needed.

-- 
Maxence Guesdon

[Ocaml-lib-devel] Ocaml indent?

[Brian H. <bri...@ql...>]

Something just occurred to me.  CVS has the ability to run a script on 
commits- explicitly, this is so you can run indent on code being 
committed.  For those who don't know, indent is a program which 
(re-)indents C code.  Allowing you to enforce convention like "no tabs", 
"curly braces on their own lines", etc.

If something like this existed for Ocaml, we could use to force indenting 
rules (once they are settled on).

Brian

[Ocaml-lib-devel] Re: [Caml-list] User library license

[Brian H. <bri...@ql...>]

Changing lists...

On Mon, 24 Feb 2003, Blair Zajac wrote:
> 
> I see a difference between a kernel which definitely can be made
> proprietary from language or core library extensions, which I see are
> just tools to make proprietary code.

I agree.  The kernel and compiler are GPL, the library is LGPL.  Exactly 
the situation that is on Linux- Linux and GCC are GPL, glibc is LGPL.

You can use the GPL'd GCC compiler to produce propreitary code just fine.  
You just can't reuse, or link with, the GPL'd code- so you can't include 
parts of the compiler in your proprietary project.

> I wouldn't have an issue with this.  I see getting improving the core
> language to be more important than license issues.  After all, these
> libraries are not

I agree- we have to work with the language as it is.

> 
> I would use the C++ Boost library as an example of people contributing to
> a high quality library.  Parts of the Boost library may be accepted by the
> C++ standards body for future standardization.  I would guess that many
> people would be proud to get their code into such a library

And this governed the license requirements.  They greatly increased the 
possibility of being included as a standard with the restictions they put 
down.  The C++ libraries have too many reimplementations- Microsoft, Sun, 
HP, IBM, GNU, etc.  All of whom have votes on the standards committee, and 
are disinclined to have to do more work than necessary to implement the 
standards.  Forcing them to rewrite large amounts of code is unplatable, 
and would likely cause them to veto the proposed library extensions.  On 
the other hand, if you give them an implementation (preferrably one that 
already works on their compiler), so that all they have to do is package 
up the library with the next release of their compiler, they'll be more 
likely to be in favor of the proposal.

Ocaml is a different situation.  With the possible exception of F#, there 
is only one implementation.

Brian