[Caml-list] Hashtbl.keys

[Caml-list] Hashtbl.keys

[Oliver Bandel]

Hello,

the Hastbl-module is a fine thing. To have functions like
Hastbl.find_all is convenient for a lot of problems, which would
be not so easy to solve, when only hastbl.find would be in
that library.

Well... and Hashtbl.iter seems to work on *all* antries in the
*whole* hash-table, that is: A Hastbl.find_all  for each of the
keys in that table.
At least it is, how I understand the decription in the manual.

Well, but Hashtbl.iter is used for unit-functions.
But I need bool-functions, and maybe other tyopes
too.

So, if I want to apply a function with return-type different then
unit, I have to use a second Hash-table to remember, which
keys I have inside my main hastbl (using hashtbl.replace).

Or I may have to use Hastbl.replace instead of Hastbl.add
in my main Hashtbl, where my new data-entry is a list of
the old entry with the new entry appended.

But that all would be easier, if there would be a function
Hashtbl.keys, which give back all keys of a hashtbl.


So, Hashtbl.keys would have the following type:

('a, 'b) t -> key 'a list


With that function, I could use things like

##################################################
let myhash = Hashtbl.create 100000;;

Hashtbl.add myhash "k1" "hellO";;
Hashtbl.add myhash "k2" "xxx";;
Hashtbl.add myhash "k3" "iuzwiuezriuw";;

Hashtbl.add myhash "k1" "la la la";;
Hashtbl.add myhash "k1" "shoo bi doo";;

Hashtbl.find_all (Hashtbl.keys myhash) 

(*
   But the later function could also be named
   Hashtbl.values
   and this one may makes sense in the Hashtbl-module
   too, but a Hashtbl.keys would be much more necessary!

   let all_values_of_a_hash hash = Hashtbl.find_all(Hashtbl.keys hash)

   But I think, the implementation could be more efficient, when
   doing the latter function directly in the underwood of the
   Hashtbl-module itself.

*)
##################################################


Wouldn't it a good idea to add such a
function "get all keys of a hashtable"
into the hashtbl-module? (And a "get all values..." to?)

Would that be hard work, or can it be added easily?


What workaround makes sense until such a funtion will
be available?
Should I use a second hash to save all keys
of the main-hash?
Or what is a good way to solve this problem?


Ciao,
   Oliver


P.S.: For a possible Ocaml-advocacy discussion I want to drop
      that note here:

      I can't believe that programming such problems in perl
      should be easier than in Ocaml... in perl there is a function
      "keys" as well as a function "values" for working on hash-tables.


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Hashtbl.keys

[Hal Daume III]

I actually find the OCaml hash table implementation to be very lacking and
have thus written my own, which probably isn't as efficient.  Nevertheless
you can find it at http://www.isi.edu/~hdaume/hashtable.ml.  It requires
garray.ml(i) found at the same location.  It doesn't have a keys function,
but such a thing is easy to write:

> let get_keys = fold (fun l k _ -> k :: l) []

You could probably do it marginally more efficiently by looking at the
actual implementaiton.

The reason I wrote this not-incredibly hash table implementation is
essentially because I needed a map function for hash tables and there was
no way to implement that on top of the current HashTbl interface.  I would
be more than happy to go back to the standard interface if it supported
maps.

--
Hal Daume III

 "Computer science is no more about computers    | hdaume@isi.edu
  than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

On Tue, 18 Feb 2003, Oliver Bandel wrote:

> Hello,
> 
> the Hastbl-module is a fine thing. To have functions like
> Hastbl.find_all is convenient for a lot of problems, which would
> be not so easy to solve, when only hastbl.find would be in
> that library.
> 
> Well... and Hashtbl.iter seems to work on *all* antries in the
> *whole* hash-table, that is: A Hastbl.find_all  for each of the
> keys in that table.
> At least it is, how I understand the decription in the manual.
> 
> Well, but Hashtbl.iter is used for unit-functions.
> But I need bool-functions, and maybe other tyopes
> too.
> 
> So, if I want to apply a function with return-type different then
> unit, I have to use a second Hash-table to remember, which
> keys I have inside my main hastbl (using hashtbl.replace).
> 
> Or I may have to use Hastbl.replace instead of Hastbl.add
> in my main Hashtbl, where my new data-entry is a list of
> the old entry with the new entry appended.
> 
> But that all would be easier, if there would be a function
> Hashtbl.keys, which give back all keys of a hashtbl.
> 
> 
> So, Hashtbl.keys would have the following type:
> 
> ('a, 'b) t -> key 'a list
> 
> 
> With that function, I could use things like
> 
> ##################################################
> let myhash = Hashtbl.create 100000;;
> 
> Hashtbl.add myhash "k1" "hellO";;
> Hashtbl.add myhash "k2" "xxx";;
> Hashtbl.add myhash "k3" "iuzwiuezriuw";;
> 
> Hashtbl.add myhash "k1" "la la la";;
> Hashtbl.add myhash "k1" "shoo bi doo";;
> 
> Hashtbl.find_all (Hashtbl.keys myhash) 
> 
> (*
>    But the later function could also be named
>    Hashtbl.values
>    and this one may makes sense in the Hashtbl-module
>    too, but a Hashtbl.keys would be much more necessary!
> 
>    let all_values_of_a_hash hash = Hashtbl.find_all(Hashtbl.keys hash)
> 
>    But I think, the implementation could be more efficient, when
>    doing the latter function directly in the underwood of the
>    Hashtbl-module itself.
> 
> *)
> ##################################################
> 
> 
> Wouldn't it a good idea to add such a
> function "get all keys of a hashtable"
> into the hashtbl-module? (And a "get all values..." to?)
> 
> Would that be hard work, or can it be added easily?
> 
> 
> What workaround makes sense until such a funtion will
> be available?
> Should I use a second hash to save all keys
> of the main-hash?
> Or what is a good way to solve this problem?
> 
> 
> Ciao,
>    Oliver
> 
> 
> P.S.: For a possible Ocaml-advocacy discussion I want to drop
>       that note here:
> 
>       I can't believe that programming such problems in perl
>       should be easier than in Ocaml... in perl there is a function
>       "keys" as well as a function "values" for working on hash-tables.
> 
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Hashtbl.keys

[Xavier Leroy]

> Well... and Hashtbl.iter seems to work on *all* antries in the
> *whole* hash-table, that is: A Hastbl.find_all  for each of the
> keys in that table.
> At least it is, how I understand the decription in the manual.
> 
> Well, but Hashtbl.iter is used for unit-functions.
> But I need bool-functions, and maybe other tyopes
> too.

See Hashtbl.fold, which supports traversing all entries of a hashtable
and build a result of any type.  For instance:

> So, Hashtbl.keys would have the following type:
> 
> ('a, 'b) t -> key 'a list

let keys h = Hashtbl.fold (fun key data accu -> key :: accu) h []

> Wouldn't it a good idea to add such a
> function "get all keys of a hashtable"
> into the hashtbl-module? (And a "get all values..." to?)

There would be disagreement as what the return type of these functions
should be: lists, sets, etc.  But you can easily write them with
Hashtbl.fold.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] OCaml standard library improvement

[Stefano Zacchiroli]

On Thu, Feb 20, 2003 at 10:43:43AM +0100, Xavier Leroy wrote:
> There would be disagreement as what the return type of these functions
> should be: lists, sets, etc.  But you can easily write them with
> Hashtbl.fold.

Yes, the ocaml standard library is full (i.e. empty) of a lot of
functions that could be written easily in 1 or 2 lines of ocaml code.

The same functions are the same that you find yourself rewriting in all
the applications you are writing (or linking an "helper" module written
once for all), this is really frustrating and I think make OCaml
standard library less appealing than other languages standard libraries.

I'm collecting from time to time a set of functions that can be easily
added to the standard library to fill this gap. Probably a lot of other
OCaml programmers are doing the same. Is there any chance to see this
functions in the standard library?

Better stated: if we, ocaml programmer, collect a set of functions that
are widely felt to be missing, could the OCaml team review the
corresponding implementation and add them to the ocaml standard library
in the next ocaml release?

Thanks for your attention,
Cheers.

-- 
Stefano Zacchiroli  -  Undergraduate Student of CS @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Nicolas George]

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

Le tridi 3 ventôse, an CCXI, Stefano Zacchiroli a écrit :
> I'm collecting from time to time a set of functions that can be easily
> added to the standard library to fill this gap. Probably a lot of other
> OCaml programmers are doing the same. Is there any chance to see this
> functions in the standard library?

There is a problem to solve before it: the confusion between modules
(used as namespace units) and compilation units. Supose you have a large
set of string functions, tu split, search for words, replace, and so on.
You want them all in one module, since you do not want to remember that
split_on_char is in String42, but split_on_chars is in String17. But you
do not want that as soon as you use the trivial split_on_char function,
your resulting binary includes all the bloat for KMP word search.

[-- Attachment #2: Type: application/pgp-signature, Size: 185 bytes --]

Re: [Caml-list] OCaml standard library improvement

[Stefano Zacchiroli]

On Fri, Feb 21, 2003 at 02:47:35PM +0100, Nicolas George wrote:
> (used as namespace units) and compilation units. Supose you have a large
> set of string functions, tu split, search for words, replace, and so on.

Well, my idea was not to collect a new library nor a big-scale one as
someone proposed.

Indeed I would not begin a new sourceforge project, I want simply to
collect _simple_ functions that are missing from the ocaml standard
library and that, I'm sure, every ocaml programmer have written at least
once in his life!
Just to clarify a bit more this point, these are some functions
prototype I've in my "OCAML-whishlist.txt" file (please don't start now
discussing on them, I report some of them only for passing you my idea):

  - val Hashtbl.keys: ('a, 'b) Hashtbl.t -> 'a list
  - val Hashtbl.values: ('a, 'b) Hashtbl.t -> 'b list
  - val String.explode: string -> char list
  - val String.implode: char list -> string
  - val non: ('a -> bool) -> ('a -> bool)
  - val Dbm.fold_left: ...
  - val Sys.copy: ...
  - val List.assoc_all: ...
  - ... and so on ...

The reason I don't want to start a sourceforge project (or a savannah
one, that should be better! :-) is that these functions shoulnd't be
separated from the ocaml distribution, they should be implemented, shown
to the ocaml team for review and integrated in the ocaml standard
distribution. That's all.

We all know that the OCaml team as a lot to do and doing this work could
probably help them in making OCaml standard library more complete.

Regarding license I suppose we should ask the ocaml team what they like
to embed this functions in the standard library, I suppose LGPL could be
fine.

Regarding the "dirty" work I suppose that the better we can do is to set
up a web page with some CGI on which ocaml programmer could post
prototype of functions they would like to see in standard library
next-generation and also implementation of functions they are proposing
or proposed by someone else.
 From this page members of the ocaml team could benefit as they like,
they can only see what ocaml programmers feel is missing in the stdlib
and don't care about implementation reimplementing them or take also
implementations.

I volunteer to set up this kind of web page if we manage to reach an
agreement on this.

Cheers.

-- 
Stefano Zacchiroli  -  Undergraduate Student of CS @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Alessandro Baretta]

Stefano Zacchiroli wrote:
> On Fri, Feb 21, 2003 at 02:47:35PM +0100, Nicolas George wrote:
> 
>>(used as namespace units) and compilation units. Supose you have a large
>>set of string functions, tu split, search for words, replace, and so on.
> 
> 
> Well, my idea was not to collect a new library nor a big-scale one as
> someone proposed.
> 
> Indeed I would not begin a new sourceforge project, I want simply to
> collect _simple_ functions that are missing from the ocaml standard
> library and that, I'm sure, every ocaml programmer have written at least
> once in his life!

It takes a lot of time and work to collect function 
signatures and code, validate the former, test or prove 
correct the latter, cut and paste the code into the cvs 
version of the library, revalidate and retest the whole 
thing, and finally distribute it.

I have my own ocamllib-addons findlib module which contains 
my additions to the standard library. I think this approach 
wins. Some of us could maintain an ocamllib-addons project 
for everybody else. Anyone wishing to use the extended 
library would simply have to download and install one 
findlib package.

The ocaml team could then use the addons code as a basis for 
extensions to the standard library, if and when they deem a 
function or a module of sufficiently general usefulness and 
of adequate quality. The addons maintainer(s) would then 
remove the equivalent code from the addons package.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[fva]

HI all,

plese read on below Zacchiroli's suggestions...

Stefano Zacchiroli wrote:

>On Thu, Feb 20, 2003 at 10:43:43AM +0100, Xavier Leroy wrote:
>  
>
>>There would be disagreement as what the return type of these functions
>>should be: lists, sets, etc.  But you can easily write them with
>>Hashtbl.fold.
>>    
>>
>
>Yes, the ocaml standard library is full (i.e. empty) of a lot of
>functions that could be written easily in 1 or 2 lines of ocaml code.
>
>The same functions are the same that you find yourself rewriting in all
>the applications you are writing (or linking an "helper" module written
>once for all), this is really frustrating and I think make OCaml
>standard library less appealing than other languages standard libraries.
>
>I'm collecting from time to time a set of functions that can be easily
>added to the standard library to fill this gap. Probably a lot of other
>OCaml programmers are doing the same. Is there any chance to see this
>functions in the standard library?
>
>Better stated: if we, ocaml programmer, collect a set of functions that
>are widely felt to be missing, could the OCaml team review the
>corresponding implementation and add them to the ocaml standard library
>in the next ocaml release?
>
I think collecting these functions is a great idea and it might enhance 
the usability of our favourite language (I have conflicting emotions 
about this claim being true. Still...).

But if *we* (I am including all OCaml programmers here) think it worth 
building such a library, why bother the OCaml team by piling *more* work 
on them? As somebody in this lists has pointed out, they are already 
doing *harder* work on the (may I have my interest included here) module 
recursion problem & downcasts and whatnot and I trust their capability 
(and willingness) to work in whatever problems they think it worth.

Why not (self?)appoint, say, three persons (I don't care about many more 
with decision power to come to an agreement about anything) to receive 
would-be code and maintain a "big-s(c)ale library"... This may find its 
way into the Standard library or it may not, but would definitely make 
happy all these people wanting to contribute differentially to the whole 
OCaml effort...

Just an idea... Something to discuss...

Regards,

        Fran Valverde


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Amit Dubey]

Fran Valverde writes:
> But if *we* (I am including all OCaml programmers here) think it worth 
> building such a library, why bother the OCaml team by piling *more* work 
> on them? As somebody in this lists has pointed out, they are already 
> doing *harder* work on the (may I have my interest included here) module 
> recursion problem & downcasts and whatnot and I trust their capability 
> (and willingness) to work in whatever problems they think it worth.
> 
> Why not (self?)appoint, say, three persons (I don't care about many more 
> with decision power to come to an agreement about anything) to receive 
> would-be code and maintain a "big-s(c)ale library"... This may find its 
> way into the Standard library or it may not, but would definitely make 
> happy all these people wanting to contribute differentially to the whole 
> OCaml effort...
> 
> Just an idea... Something to discuss...
> 
> Regards,
> 
>         Fran Valverde


    I've been following the discussion, and I think it's a good idea.
I have to code submit, but one thing that (unfortunately!) needs
to be discussed is the license.  I usually don't follow the license threads
on this list, so I apologize if this post smacks of ignorance, but
I would suggest the LGPL is probably a good bet for such a library.
Any other suggestions?  (I am ambivalent myself, and would be happy
with the GPL or BSD licenses).

    Another note, do people think that hosting such a project on
Sourceforge might be a good idea?  If there are positive replies,
(in particular, I would be interested to hear what the core Ocaml
developers think of this idea), I will volunteer to register the
project.


Nicolas George writes:
> There is a problem to solve before it: the confusion between modules
> (used as namespace units) and compilation units. Supose you have a large
> set of string functions, tu split, search for words, replace, and so on.
> You want them all in one module, since you do not want to remember that
> split_on_char is in String42, but split_on_chars is in String17. But you
> do not want that as soon as you use the trivial split_on_char function,
> your resulting binary includes all the bloat for KMP word search.

    This is a good point, Nicolas.  However, my feeling is that this
may not be a big problem in the begining, and it might be difficult
devising a logical way to split things before we know enough about the scope
of the problem.  I'd suggest the best solution here would be to start off
keeping everything together.  If there is too much bloat, things could be
split up into smaller modules, with some larger modules that "include"
other ones to provide backwards compatibility.


    -Amit Dubey

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Brian Hurt]

On Fri, 21 Feb 2003, Amit Dubey wrote:

> 
>     I've been following the discussion, and I think it's a good idea.
> I have to code submit, but one thing that (unfortunately!) needs
> to be discussed is the license.  I usually don't follow the license threads
> on this list, so I apologize if this post smacks of ignorance, but
> I would suggest the LGPL is probably a good bet for such a library.
> Any other suggestions?  (I am ambivalent myself, and would be happy
> with the GPL or BSD licenses).

I vote for LGPL myself.  I have a Priority Search Queue implementation 
I'll submit:
http://www.informatik.uni-bonn.de/~ralf/talks/ICFP01.pdf

With respect to strings, I think what we need is a good regular expression 
parsing library.  Something less powerful than Ocamllex, but more powerful 
than strchr.

> 
>     Another note, do people think that hosting such a project on
> Sourceforge might be a good idea?  If there are positive replies,
> (in particular, I would be interested to hear what the core Ocaml
> developers think of this idea), I will volunteer to register the
> project.

Long term, I'd perfer to see it become part of the standard distribution.  
If you can gaurentee that it's always there, it'll be a lot more widely 
used.



> 
> 
> Nicolas George writes:
> > There is a problem to solve before it: the confusion between modules
> > (used as namespace units) and compilation units. Supose you have a large
> > set of string functions, tu split, search for words, replace, and so on.
> > You want them all in one module, since you do not want to remember that
> > split_on_char is in String42, but split_on_chars is in String17. But you
> > do not want that as soon as you use the trivial split_on_char function,
> > your resulting binary includes all the bloat for KMP word search.
> 
>     This is a good point, Nicolas.  However, my feeling is that this
> may not be a big problem in the begining, and it might be difficult
> devising a logical way to split things before we know enough about the
> scope of the problem.  I'd suggest the best solution here would be to
> start off keeping everything together.  If there is too much bloat,
> things could be split up into smaller modules, with some larger
> modules that "include" other ones to provide backwards compatibility.
> 

- We shouldn't be afraid to add functions/functionality to libraries.  
There should never be a string2 library, let alone a string17 library.

- We shouldn't be afraid to add new libraries either- for different 
functionality.  Regular expression parsing, for example, shouldn't be in 
the string library.

This sounds contradictory, but it's not (quite).  Every library should
have a clear domain.  I look at it in terms of code: libraries should come
in one of two forms- either collections of simple related routines with no
common infrastructure, or collections of routines which share a common 
infrastructure.

So the string library would be a collection of simple routines.  None of
the routines in string call each other, or any common 'infrastructure'
routines.  Regular expressions have infrastructure- routines to create and 
manipulate DFAs and NFAs if nothing else.  That common infrastructure then 
defines it as a seperate library- the library of everything using that 
infrastructure.

Just my $0.02.

Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Nicolas George]

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

Le tridi 3 ventôse, an CCXI, Brian Hurt a écrit :
> - We shouldn't be afraid to add functions/functionality to libraries.  
> There should never be a string2 library, let alone a string17 library.
[...]
> So the string library would be a collection of simple routines.  None of
> the routines in string call each other, or any common 'infrastructure'
> routines.

I think you misunderstoud the problem I was mentionning. A string
library should be one module, we agree. Let's say it is "String". Then
as soon as you use one function of the String module, the resulting
binary will hold _all_ the code in the String module. If you have a lot
of functions in the module (and this is what we want), you have a huge
binary. Berk.

As far as I know, there is no hack to avoid it. It would be necessary to
rethink the format of the .cmo or .cma files to allow that.

[-- Attachment #2: Type: application/pgp-signature, Size: 185 bytes --]

Re: [Caml-list] OCaml standard library improvement

[Brian Hurt]

On Fri, 21 Feb 2003, Nicolas George wrote:

> 
> I think you misunderstoud the problem I was mentionning. A string
> library should be one module, we agree. Let's say it is "String". Then
> as soon as you use one function of the String module, the resulting
> binary will hold _all_ the code in the String module. If you have a lot
> of functions in the module (and this is what we want), you have a huge
> binary. Berk.
> 
> As far as I know, there is no hack to avoid it. It would be necessary to
> rethink the format of the .cmo or .cma files to allow that.
> 

A worry that never even crossed my mind :-).

The proper solution for this, IMHO, is shared libraries.  Yeah, the 
library is huge, but there is only one copy of it for everyone.

But I'm inclined to cross that bridge when we come to it.  I'm much more 
concerned that the library won't get used because it's "inconvient".

I say, let's start gathering code, then worry about how to package it.

Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Chris Hecker]

>But I'm inclined to cross that bridge when we come to it.  I'm much more
>concerned that the library won't get used because it's "inconvient".
>I say, let's start gathering code, then worry about how to package it.

I agree with this 100%.

Are you volunteering?  :)

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Brian Hurt]

On Fri, 21 Feb 2003, Chris Hecker wrote:

> 
> >But I'm inclined to cross that bridge when we come to it.  I'm much more
> >concerned that the library won't get used because it's "inconvient".
> >I say, let's start gathering code, then worry about how to package it.
> 
> I agree with this 100%.
> 
> Are you volunteering?  :)
> 


I'm certainly willing to do the scut work.  And contribute code.  The only
thing that's causing me to slow down is that this wasn't originally my
idea.  I've lost the messages which started this thread, so I can't give
proper attribution.  And I think it's bad luck to start a project by 
torqueing people off :-).

Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[John Max Skaller]

Nicolas George wrote:

> A string
> library should be one module, we agree. Let's say it is "String". Then
> as soon as you use one function of the String module, the resulting
> binary will hold _all_ the code in the String module. If you have a lot
> of functions in the module (and this is what we want), you have a huge
> binary. Berk.
> 
> As far as I know, there is no hack to avoid it. It would be necessary to
> rethink the format of the .cmo or .cma files to allow that.


Two viewpoints:

(1) in the "old" days, one could extract only
needed functions from libraries: this kept executables small.

(2) in the modern system, the whole library is shared
and linked dynamically, so the executable doesn't include
the code at all. The actual overhead depends on how many
processes share the code.

So there are two ways forward:

(1) split libraries into
segments to ensure minimal static linkage

(2) make ocaml emit code which can be linked
into a shared library

Whilst these tasks are not mutually exclusive,

I'd see (1) as a nice optimisation, whilst (2) is
a pre-requisite for industrial acceptance.

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


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Maxence Guesdon]

>     I've been following the discussion, and I think it's a good idea.
> I have to code submit, but one thing that (unfortunately!) needs
> to be discussed is the license.  I usually don't follow the license threads
> on this list, so I apologize if this post smacks of ignorance, but
> I would suggest the LGPL is probably a good bet for such a library.
> Any other suggestions?  (I am ambivalent myself, and would be happy
> with the GPL or BSD licenses).
> 
>     Another note, do people think that hosting such a project on
> Sourceforge might be a good idea?  If there are positive replies,
> (in particular, I would be interested to hear what the core Ocaml
> developers think of this idea), I will volunteer to register the
> project.

I personally think it's a good idea.
In the cdk you will find a good basis to start such a library.
The cdk : http://pauillac.inria.fr/cdk/
Fabrice Le Fessant made a good work with his libraries in the cdk (string2,
unix2, ....) and I hope his work can be part of a collaborative "standard"
library.

-- 
Maxence Guesdon
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Nicolas Cannasse]

> Why not (self?)appoint, say, three persons (I don't care about many more
> with decision power to come to an agreement about anything) to receive
> would-be code and maintain a "big-s(c)ale library"... This may find its
> way into the Standard library or it may not, but would definitely make
> happy all these people wanting to contribute differentially to the whole
> OCaml effort...
>
> Just an idea... Something to discuss...

I agree with that point of view.

Actually the C++ STL ( although C++ is not perhaps the better sample when
talking about programming languages... ) is distributed and developped
seperatly from compilers. Of course there is several compilers but...
Indeed perhaps we ( the ocaml programmers interested in developping the
"ocaml -extended- standard library" ) should only need a separate mailling
list ( to discuss about implementations choices such as tail recursive
calls ) and perhaps a CVS tree... so maybe a sourceforge project would be
nice here.
I would be more than happy to join such a project.

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Chris Hecker]

>"ocaml -extended- standard library" ) should only need a separate mailling
>list ( to discuss about implementations choices such as tail recursive
>calls ) and perhaps a CVS tree... so maybe a sourceforge project would be
>nice here.

I agree with this as well.  Like the other point about packagin, I think 
worrying about getting the code into the main distribution and packaging 
and whatnot is premature.  Let's just start a sourceforge project and get 
some code together.  If it's useful, we'll solve the distribution problems 
as they come up.

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Brian Hurt]

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.

Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Stefano Zacchiroli]

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

-- 
Stefano Zacchiroli  -  Undergraduate Student of CS @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[fva]

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.
>
>Brian
>  
>
How'bout the name given by Baretta "ocamllib-addons"? I guess we (this 
thread's community, I mean) roughly agree on the rest...

BTW, I don't think I can manage a Sourceforge project right now, but I 
will be very willing to contribute my own code snippets to such a thing.

Regards,

        Francisco Valverde



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Amit Dubey]

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


    Hi Brian (and list),

    I mentioned earlier on the list that I'd get a Sourceforge account.
I've already done this.  I wasn't very creative with the name, so it
is simply (and perhaps, unfortunately) called ocaml-lib.sourceforge.net.

    I've got two a conference deadlines on Wednesday, so that's why
I've been quiet on the list, but if all willing volunteers get
sourceforge announts, I'll figure out how to allow them to do
CVS checkout/checkins.

    I took a few mintues to get the extlib from the CDK and make
a couple additions, but I haven't submitted this to the CVS yet.
(Maxence - were you suggesting that we should maintain the whole
CDK there, or just the extlib?)

    The license is LGPL, but I am convinced by Sven's comments,
and I think LGPL + OCaml runtime extensions is probably best (if the
goal is to eventually convince the core team to include it with
the distribution).  Should I try to contact the sourceforge people
to ask for a change before any work is done?

    -Amit

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[John Max Skaller]

It's not enough to just start a sourceforge account.
Some strict policy is needed for managing contributions.
The C++ Boost is an example of an informal collaborative effort
and is worth looking at. The Library Working Group of the C and
C++ ISO committees are another, and are also worth considering.

Basically: the last thing a standard library needs is a huge
set of ad hoc functions added with overlapping functionality
and confusing naming schemes, argument passing protocols, etc.

One mechanism to handle this is for each developer to
work on a CVS branch, and conduct a discussion and vote
on including the branch in the mainstream. One or two trusted
people should perform the actual merging when they think
there is consensus the branch is ready and suitable for inclusion.

One of the virtues of the current ocaml library is that it
is relatively small and covers a reasonable amount of territory.

For the record, the C++ LWG had a policy of considering proposals
which had one of two properties:

1) it provided important functionality which was hard
for the client to code up correctly

2) it provided a simple convenience which would be
heavily used

Any proposal degrading performance needed exceptionally
compelling arguments to be accepted.

The process resulted in a couple of bad decisions,
but it also resulted in a reasonably small and consistent
library.

Anyhow, I'd urge people pause before 'contributing code'
because that isn't important. The key thing is to create
a policy document that clearly states the project goals,
and to apply the policy strictly.


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


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Lauri Alanko]

On Mon, Feb 24, 2003 at 11:56:00PM +1100, John Max Skaller wrote:
> It's not enough to just start a sourceforge account.
> Some strict policy is needed for managing contributions.
> The C++ Boost is an example of an informal collaborative effort
> and is worth looking at. The Library Working Group of the C and
> C++ ISO committees are another, and are also worth considering.

Another thing to look at is the SRFI system for Scheme
<http://srfi.schemers.org/>. It is a systematic yet fairly informal and
accessible procedure for defining language and library extensions, and
it has proven to produce well-specified and fairly clean designs (along
with implementations, of course).


Lauri Alanko
la@iki.fi
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Sven Luther]

> Anyhow, I'd urge people pause before 'contributing code'
> because that isn't important. The key thing is to create
> a policy document that clearly states the project goals,
> and to apply the policy strictly.

But the discusion could now be ported to a separate mailing list on the
new sourceforge project, could it not ? The licence flamewar also i
guess.

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Library Discussion Followups

[Amit Dubey]

> 
> > Anyhow, I'd urge people pause before 'contributing code'
> > because that isn't important. The key thing is to create
> > a policy document that clearly states the project goals,
> > and to apply the policy strictly.
> 
> But the discusion could now be ported to a separate mailing list on the
> new sourceforge project, could it not ? The licence flamewar also i
> guess.
> 

    Good idea, Sven!

    I've created a mailing list, and you can sign up at:

    http://lists.sourceforge.net/lists/listinfo/ocaml-lib-devel

    The project page is it:

    http://sourceforge.net/projects/ocaml-lib/

    -Amit

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[John Max Skaller]

Sven Luther wrote:

>>Anyhow, I'd urge people pause before 'contributing code'
>>because that isn't important. The key thing is to create
>>a policy document that clearly states the project goals,
>>and to apply the policy strictly.
>>
> 
> But the discusion could now be ported to a separate mailing list on the
> new sourceforge project, could it not ? The licence flamewar also i
> guess.


I have 3 sourceforge projects, and I think that while it

is clumbsy at doing some things it does have a lot of support
and reasonable management tools. I can't speak for savannah.
Sourceforge downside: FTP is not supported BAHHHH HUMBUG don't these
people know that HTTP is unreliable? :-) Also the release mechanism
is exceedingly clumbsy, and they don't allow computations on the
main shell accounts -- last I looked the computation farm required
manually moving stuff around.

On licence: given the goal to extend/round out the standard
ocaml library, I think our feelings on the licence are fairly moot.
We should simply use the same licence as the library we're extending.

ON worthy subgoal would be to *eliminate* the other licences:
I believe the Str module is archaic and has 'other licence'
and we might try to eliminate it -- the Ocaml team itself is
working on that isn't it?

[Sigh: my FSA code already replaces Ocamllex, but it's FFAU:
more work is needed, but if other contributions were LGPL
I wouldn't be able to use them unless I rethought my licence policy]

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


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Xavier Leroy]

> ON worthy subgoal would be to *eliminate* the other licences:
> I believe the Str module is archaic and has 'other licence'
> and we might try to eliminate it -- the Ocaml team itself is
> working on that isn't it?

Right.  In the working sources, Str was reimplemented from scratch,
and the new implementation is entirely under the same license as all
other libraries (LGPL minus clause 6).

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Benjamin C. Pierce]

I'm all in favor of improving the standard library, but...

  1) I agree that such a project will be most useful if there is some
     kind of strong unifying vision

  2) I suggest looking at the SML Basis Library for ideas -- the people
     that designed it thought a *lot* about consistent naming and such.
     (In fact, would it be a bad idea just to *copy* the SML basis APIs
     verbatim?)

  3) I question whether this is actually the most-needed thing... see
     next message...

         -- Benjamin

-----------------------------------------------------------------------------
BENJAMIN C. PIERCE, Professor
Dept. of Computer & Information Science                bcpierce@cis.upenn.edu
University of Pennsylvania                                    +1 215 898-2012
200 South 33rd St.                                       Fax: +1 215 898-0587
Philadelphia, PA 19104, USA                http://www.cis.upenn.edu/~bcpierce
-----------------------------------------------------------------------------


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[brogoff]

On Mon, 24 Feb 2003, Benjamin C. Pierce wrote:
> I'm all in favor of improving the standard library, but...
> 
>   1) I agree that such a project will be most useful if there is some
>      kind of strong unifying vision
> 
>   2) I suggest looking at the SML Basis Library for ideas -- the people
>      that designed it thought a *lot* about consistent naming and such.
>      (In fact, would it be a bad idea just to *copy* the SML basis APIs
>      verbatim?)

That's a great idea! There are a few things that would need to change, of 
course, like transforming tupled arguments to curried ones, and probably 
changing interCap function names to caml_style_underscore_separated ones
but I think just staying as close as possible to the SML Basis makes a lot of 
sense for a number of reasons. 

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Diego Olivier Fernandez Pons]

    Bonjour,

On Mon, 24 Feb 2003, Benjamin C. Pierce wrote:

> I'm all in favor of improving the standard library, but...
>
>   1) I agree that such a project will be most useful if there is some
>      kind of strong unifying vision
>
>   2) I suggest looking at the SML Basis Library for ideas -- the people
>      that designed it thought a *lot* about consistent naming and such.
>      (In fact, would it be a bad idea just to *copy* the SML basis APIs
>      verbatim?)

I am afraid I am not familiar with the whole SML/NJ library (rather
than SML Basis Library which is quite sparse), the only thing I can
truly say is that :

- SML/NJ library already copies in some points Caml standard library :

e.g. The pretty printing (smlnj-lib/PP) is a port of Pierre Weis one

- SML/NJ library may not be the best library to copy since :

smlnj-lib/Regexp is not superior to Marché's Regexp (classical RE lib,
compiled to dfa or directly interpreted), Vouillon's LibRE (lazy
automata building), or to Galax (Glushkov construction)
(I have not yet seen Leroy's Str new implementation)

smlnj-lib/Util is not really superior to the data structures already
avaible in Caml (standard library, JCF's Patricia trees, ...)

smlnj-lib/HashCons is mostly equivalent to JCF ones (I remember having
read somewhere that JCF actually used some tricks found in the SML/NJ
library)

smlnj-lib/Doc is not superior to OCamlDoc

Concerning SML-Basis, if a common naming for all SML libraries was a
good idea, I am afraid SML-Basis is really not enough, just providing
some quite trivial minimal interfaces. And I do not really feel that
SML-Basis has done, even for the few functions it provides, the 'best'
choices avaible.

I agree that looking in other libraries for ideas is a good thing,
but this seems to have already be done concerning SML libraries.


        Diego Olivier


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library improvement

[Jean-Christophe Filliatre]

 > smlnj-lib/HashCons is mostly equivalent to JCF ones (I remember having
 > read somewhere that JCF actually used some tricks found in the SML/NJ
 > library)

No, that's incorrect.  I built this library from  scratch, without any
knowledge of something similar in SML/NJ.

But someone pointed to me later  that I used some trick similar to one
used  in SML/NJ  hash tables  (namely,  to keep  the hash  key in  the
buckets to avoid its recomputation when resizing the hash table).

-- 
Jean-Christophe

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] OCaml standard library _improvement_ NOT a new library!

[Stefano Zacchiroli]

As the source of this post-fest let me restate what was my original
idea that definitely collide with sourceforge project and similar ...

My idea was not to start a new ocaml library project full of a lot of
really useful functions but split away from the ocaml team ocaml
distribution. We already have many of them and no one of them managed to
succeed in be widespreaded enough (CDK is surely the best example!).

What I proposed was to collect a set of additions to the ocaml
_standard_ library so that ocaml implementors can take suggestions
and/or code from the ocaml programmers. This code was supposed to
_be_part_of_the_ocaml_standard_library_, not a fork.

In order to be part of the ocaml standard library functions should be:
- a few and not tons
- with interfaces and names similar to functions that already exist in
  the standard library
- addons and not implementation of new impressive data structures, they
  don't need to be part of a standard library
- recyclable as single units and not only as a whole library so that
  memebers of the ocaml team could pick single functions
- with a license compatible with ocaml sources, the beter obviously is
  the same license of the rest of ocaml sources

Anyone can be useful following this idea submitting small whishlist bug
reports including implementations of functions for the stdlib, but
creating a group which agree on a set of common functions is probably
better.

If someone is interested in working on such an approach please mail me
privately so that we can share ideas and code to propose to the ocaml
team.

Cheers.

-- 
Stefano Zacchiroli  -  Undergraduate Student of CS @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library _improvement_ NOT a new library!

[Alessandro Baretta]

Stefano Zacchiroli wrote:

> What I proposed was to collect a set of additions to the ocaml
> _standard_ library so that ocaml implementors can take suggestions
> and/or code from the ocaml programmers. This code was supposed to
> _be_part_of_the_ocaml_standard_library_, not a fork.

Stefano, do you have authority to make changes to the Ocaml 
standard library distribution? I don't. The best I can do is 
distribute my ocamllib-addons, as I call them, and let the 
Ocaml team pick whatever they like for the sake of inclusion 
into the standard library. The addons package only contains 
whatever code isn't already in the standard distribution, 
and as the caml team takes functions from this package for 
the standard library, such functions will be purged from the 
addons package.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml standard library _improvement_ NOT a new library!

[Stefano Zacchiroli]

On Tue, Feb 25, 2003 at 10:43:21PM +0100, Alessandro Baretta wrote:
> >and/or code from the ocaml programmers. This code was supposed to
> >_be_part_of_the_ocaml_standard_library_, not a fork.
> Stefano, do you have authority to make changes to the Ocaml 
> standard library distribution? I don't.

I haven't too, but coding something with the _idea_ that it will be well
suited to be included in the ocaml standard library is completely
different than coding a new library.

For example, if you are planning do improve the standard library you
surely have to get more in touch with the ocaml team to know what they
think of a stdlib.

Cheers.

-- 
Stefano Zacchiroli  -  Undergraduate Student of CS @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Hashtbl.keys

[Alex Cowie]

The documentation of Hashtbl.iter and Hashtbl.fold states:
	The order in which the bindings are passed to f is unspecified. 	
	Each binding is presented exactly once to f.
Given that other operations on Hashtbl preserve the reverse order of 
introduction for bindings for a particular key value, do iter and fold 
also preserve the (reverse) order of introduction for bindings for a 
particular key.  Without a guarantee of this partial ordering, iter and 
fold would be much less useful in constructing map and similar 
transformations on tables where multiple bindings for a key are allowed. 
    If the partial ordering does hold, can this be added to the 
documentation of iter and fold.

If a table is constrained to have only one binding per key (eg through 
using Hashtbl.replace as the add operator) then the lack of ordering 
becomes less of an issue.

Alex Cowie,
School of Computer and Information Science,
University of South Australia.

Xavier Leroy wrote:

>>Well... and Hashtbl.iter seems to work on *all* antries in the
>>*whole* hash-table, that is: A Hastbl.find_all  for each of the
>>keys in that table.
>>At least it is, how I understand the decription in the manual.
>>
>>Well, but Hashtbl.iter is used for unit-functions.
>>But I need bool-functions, and maybe other tyopes
>>too.
>>
> 
> See Hashtbl.fold, which supports traversing all entries of a hashtable
> and build a result of any type.  For instance:
> 
> 
>>So, Hashtbl.keys would have the following type:
>>
>>('a, 'b) t -> key 'a list
>>
> 
> let keys h = Hashtbl.fold (fun key data accu -> key :: accu) h []
> 
> 
>>Wouldn't it a good idea to add such a
>>function "get all keys of a hashtable"
>>into the hashtbl-module? (And a "get all values..." to?)
>>
> 
> There would be disagreement as what the return type of these functions
> should be: lists, sets, etc.  But you can easily write them with
> Hashtbl.fold.
> 
> - Xavier Leroy
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> 
> 


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners