ocaml-lib-devel — Developer's mailing list

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

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

> > 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...
> 
> How much of a problem is this?  I mean, to do:
> let foo x y = bar y x ;;
> strikes me as being seriously trivial.

Yes, but it really bothers me to define such functions in my code, because I must find a not conflicting and still meaningful name for these, or use
a function defined "on the fly".
Example :
I have a set module MySet (result of the Set.Make functor), containing the function
add :  elt -> t -> t

Now if I want to build a MySet.t from a list, I use fold_left like this :
  List.fold_left (fun set e -> MySet.add e set) MySet.empty my_list

I could have used 
  List.fold_right MySet.add my_list MySet.empty
but fold_right is not tail-recursive, so I think MySet.add should have the type
add : t -> elt -> t

In this case, I would not have to pollute my code with 
  (fun set e -> MySet.add e set)

You can say the workaround is trivial, but it happens quite often.

> A bigger problem for me is to make the arguments in a standard order.  One 
> thing that *always* annoys me in C is:
>     fprintf(stream, "string");
>     fputs("string", stream);
> 
> I'd much perfer to have a standard order for arguments, to make them 
> easier to remember.  For example, in data-structure oriented APIs, the 
> data structure to act upon/use should always be the first argument.  Etc.

I agree. 

> Having to look up the order of arguments every time you use the function 
> encourages programmers to not use the function.

I agree again.

-- 
Maxence Guesdon

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

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

On Wed, 26 Feb 2003, John Max Skaller wrote:

> 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.

I have to agree with you there.  Plain make is nigh unto unusable, even 
for a small project (dozens of files).  Requiring gnu make helps, but 
doesn't solve the problem- for example, how do you write a rule that deals 
with yacc outputting both a foo.c and a foo.h, such that if either file 
needs to be rebuilt yacc is run, but if both files need to be rebuilt yacc 
is only run once?  I still haven't solved that one.  And I'm not sure it's 
solvable.

For the record, I also dislike ant.  If I was willing to forego partial 
recompilation and dependency checking, I'd write a fargin shell script.  

Brian

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

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

On Tue, 25 Feb 2003, Nicolas Cannasse wrote:

> 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 :)
> 

I agree that having six different tree implementations- or even just six 
different map implementations- isn't usefull.  But one of the things I 
like about Java is it's (bloated, huge) libraries.  Yes, it makes Java 
have a footprint that would shock a brontosaurus, but it also makes Java 
programmers more likely to use the libraries that exist.  Why write your 
own (badly implemented and non-conformant) XML parser when you can just 
use the (well implemented and conformant) standard XML parser?  Why write 
your own configuration file parser when you can use XML?  Etc.

Huge libraries- like GUI interface or 3D libraries- should be on their 
own.  But unless we're talking megabytes of library here, I'd perfer to 
download and install *one* library, not thirty.  And, IMHO, XML parsing is 
small enough and there are enough possible uses for it that I'd like it in 
the library.

Note that the definition for inclusion shouldn't just be *current* uses, 
but also *potiential* uses were it everywhere.  Take XML for example- it 
probably isn't a bad format for configuration files, should an XML parser 
be handy.  It's almost certainly not worth it to write an XML file parser 
just to parse your configuration file, but if it was there, people would 
use it for that.

Brian

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

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

On Tue, 25 Feb 2003, fva wrote:

> 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?

I'd be as much or more concerned with 'political' interference at Savannah 
as I'd be at SourceForge.  This may come as a surprise, being that I am a 
big GPL fan, but several of RMS' moves recently scare me.  In addition to 
the whole lignux / gnu/linux thing, consider this as well:
http://slashdot.org/article.pl?sid=01/08/19/2039211&mode=nested

IMHO, Stallman has gotten a stick up his butt recently about being 
'forgotten' by the open/free source community.  As if that could happen.  
What I really think is happening is that he is not the only big figure 
anymore- the playing field has opened up, and lots more people have made 
names for themselves- Linus, Miguel, Xavier (hey, I can dream, can't I?), 
etc.

Not that SourceForge is beyond reproach by any strech of the imagination.  
I'd be much happier with a box controlled by someone known on this list.  
But as I don't have that box to offer, I haven't been offering an opinion.

Brian

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

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

On Tue, 25 Feb 2003, Maxence Guesdon wrote:

> 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...

How much of a problem is this?  I mean, to do:
let foo x y = bar y x ;;
strikes me as being seriously trivial.

A bigger problem for me is to make the arguments in a standard order.  One 
thing that *always* annoys me in C is:
    fprintf(stream, "string");
    fputs("string", stream);

I'd much perfer to have a standard order for arguments, to make them 
easier to remember.  For example, in data-structure oriented APIs, the 
data structure to act upon/use should always be the first argument.  Etc.
Having to look up the order of arguments every time you use the function 
encourages programmers to not use the function.

Speaking of which- I came upon an issue writting my psqueue library.  For 
data structures that have uniqueness constraints (hashes, trees, etc) what 
happens when you add an element that is already there, or modify/remove an 
element that isn't there?  There are two sets of ideology on this that I 
know of:

- The "loose" philosophy- quietly do "the right thing".  Adding an element
(or key)  that already exists simply replaces the previous element(key).  
Removing or modifying a key that doesn't exist does nothing.  The belief 
here is that what the programmer meant, or what is likely to do the least 
damage, is obvious, and you shouldn't blow up the entire program when 
there is an obvious way to continue.

- The "strict" philosophy- throw an exception on these cases.  The 
programmer asked to do something "nonsensical" and should fix his program, 
rather than take the chance that the library will guess wrong what the 
correct behavior is.  And the sooner the library helps the programmer 
catch his mistake, the easier it is to fix.

My "solution" is to provide both and let the programmer pick which he
wants.  IIRC, I used add/remove for the loose versions, and insert/delete
for the strict versions.


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

My general philosophy on labels is that they should only be used when 
there is a real good reason to use them.  What a 'real good reason' is I'm 
still working on.

Brian

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

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

On Wed, Feb 26, 2003 at 04:38:15AM +1100, John Max Skaller wrote:
> >>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. 

Indeed. I actually now think that we should not rely on anything
the ocaml core team does not rely on. Under unix, that means
ocaml and make. If they don't need python to install the ocaml
libraries, we don't need it for ExtLib either.

So, my proposal would be like this: we create a `ocamlc -where`/extlib
directory, with extlib.cm* files in it. To use extlib, 
you need to compile with +extlib extlib.cma. (Please
forgive my unixisms; if something will not work under
Windows, please free to suggest alternatives that will).

Now, for the level of the library, what I see for the first
phase is (I think) very close to Stefano's:
We need things like String.of_char and List.rev_combine.
It seems to me that the simplest way to get them is by writing
.ml files like this string.ml:

   include String
   let of_char = String.make 1

and .mli files that replicate the string.mli from the stdlib and
add the extensions of extlib. Then we just pack everything in
extlib.cma. The ocaml team can decide to move things for stdlib
to extlib (or the other way round) as they wish.

> 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...

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