ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] [Fwd: Re: [Caml-list] Strings as arrays or lists...]

[Olivier A. <an...@ij...>]

 fva [Monday 3 March 2003] :
 > OOps! I guess X. Leroy is giving a strong hint *against*
 > inefficient code in the ExtLib... Anybody else reads it likewise?

[ Sorry about last mail ... ]

I think it's OK to have inefficient code as long as the user is fully
aware he is using inefficient code and has good reasons to use it. The
point of representing string as char list is that you can apply it to
polymorphic functions that work for any list. Personally, I almost
never encountered such a situation.

So, IMHO, the important issue is that these functions are not very
useful; the fact that they are inefficient is only secondary. [But of
course this depends much on what kind of programs you write and I
guess some people really need this list representation.]

-- 
   Olivier

Re: [Ocaml-lib-devel] [Fwd: Re: [Caml-list] Strings as arrays or lists...]

[Olivier A. <an...@ij...>]

 fva [Monday 3 March 2003] :
 >
 > OOps! I guess X. Leroy is giving a strong hint *against* inefficient 
 > code in the ExtLib... Anybody else reads it likewise?

[Ocaml-lib-devel] [Fwd: Re: [Caml-list] Strings as arrays or lists...]

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

  OOps! I guess X. Leroy is giving a strong hint *against* inefficient 
code in the ExtLib... Anybody else reads it likewise?

Regards,

        Fran Valverde

> > in Haskell, strings are lists of chars.
> 
> And what a horrible design decision that is!

Agreed.  

Actually, the list representation of strings is so repugnant that I
don't even want to include "explode" and "implode" coercions between
string and char list in the standard library.  A standard library
should steer users away from algorithmically-inefficient code.  By not
having implode and explode in the library, I hope OCaml programmers
will come to the realization that the proper way to operate on strings
is either via block operations (the String module, regexps, etc), or
by recursion on integer indices.

- Xavier Leroy

Re: [Ocaml-lib-devel] ExtLib v0.1o

[William D. N. <wne...@cs...>]

On Sun, 2 Mar 2003, Blair Zajac wrote:
> > > Can we rename MList to something more descriptive, such as List_Mutable?
> >
> > And after several times List_Mutable.iter is getting
> > really verbose ( by the way that seems to be the caml team opinion as well
> > since we have Hashtbl and not Hashtable module )
>
> Well, Hashtbl is at least understandable what it is, shortening Mutable to
> M is not.

I agree with this.  Every time I see MList, it gets parsed as ML-ist (like
duelist or trombonist) rather than M-List, and it takes me time to
remember what the heck an ML-ist is...

My vote would go for a longer more descriptive name such as Mutable_List
(+0.9) or Mut_List (+0.6).  Besides, aren't long, commonly used
identifiers why jeebus invented keyboard macros?

William D. Neumann

---

"Well I could be a genius, if I just put my mind to it.
And I...I could do anything, if only I could get 'round to it.
Oh we were brought up on the space-race, now they expect you to clean toilets.
When you've seen how big the world is, how can you make do with this?
If you want me, I'll be sleeping in - sleeping in throughout these glory days."

	-- Jarvis Cocker

Re: [Ocaml-lib-devel] ExtLib v0.1o

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

Nicolas Cannasse wrote:
> 
> > If you use a particular name enough, then you could always do
> >
> >     let miter = List_Mutable.iter
> >
> > in your code.  So this gets your short names and gets me my long names.
> 
> You could on your side do :
> 
> module List_Mutable = ExtLib.MList

Granted.

> 
> Yes, perhaps it's not obvious, but the documentation is here for that !

The code is the documentation!

> for example the modules "Weak" , "Oo", "Complex" from the standard library
> are not so obvious names. But you only have to open the doc to get it.

I'm not debating these names.  Anybody who's studied C++ has probably seen
the Complex type, can figure out that Oo means ObjectOriented, and Weak means
weak and would have to be looked up.

I just have issue with shorting Mutable to M.  If it were MutList, then my
objections would be reduced.  MutList is the same length as Hashtbl.

Why don't we take this to a vote on the list.  Right now we're tied :)

While we're on voting, I propose we introduce a voting mechanism to see
decide issues.  I like the Apache voting mechanism and have used it before:

    Expressing Votes: +1, 0, -1, and Fractions

    The voting process in Apache may seem more than a little weird if you've
    never encountered it before. Votes are represented as numbers between -1
    and +1, with '-1' meaning 'no' and '+1' meaning 'yes.'

    The in-between values are indicative of how strongly the voting individual
    feels. Here are some examples of fractional votes and ways in which they
    might be intended and interpreted:

    +0: 'I don't feel strongly about it, but I'm ok with this.' 

    -0: 'I won't get in the way, but I'd rather we didn't do this.' 

    -0.5: 'I don't like this idea, but I can't find any rational justification
    for my feelings.' 

    ++1: 'Wow! I like this! Let's do it!' 

    -0.9: 'I really don't like this, but I'm not going to stand in the way if
    everyone else wants to go ahead with it.' 

    +0.9: 'This is a cool idea and i like it, but I don't have time/the skills
    necessary to help out.' 

    -1: 'I strongly disagree'

More info:

    http://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=apache+voting

Best,
Blair

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

Re: [Ocaml-lib-devel] ExtLib v0.1o

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

> If you use a particular name enough, then you could always do
>
>     let miter = List_Mutable.iter
>
> in your code.  So this gets your short names and gets me my long names.

You could on your side do :

module List_Mutable = ExtLib.MList

> I'm concerned that when COAN gets going, there's going to be name
collisions
> and choosing very short names will lead to collisions later on.

The "-pack" option is resolving most of the cases. By the way, the more you
use some functions, so more they have to be short named. I personnally think
that mutable lists are the kind of module with large potential usage ( the
whole ExtLib is, actually )

> > > I think this would be relevant and consistent with other module
> > distributions,
> > > such as different XML parsing modules that would all be named with an
XML*
> > > prefix.
> >
> > I think that MList is understandable enough for the average user.
>
> Not claiming to be an average user :)  (Most Ocaml users probably aren't)
> It wasn't for me.  In the week that MList was first discussed and when I
> got around to looking at ExtLib, I had already forgotten what MList meant.

Yes, perhaps it's not obvious, but the documentation is here for that !
for example the modules "Weak" , "Oo", "Complex" from the standard library
are not so obvious names. But you only have to open the doc to get it.

Nicolas Cannasse

Re: [Ocaml-lib-devel] ExtLib v0.1o

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

Nicolas Cannasse wrote:
> 
> > > Hi list
> > >
> > > Here's most of the functions ( sorted by module ) that I been gathered
> from
> > > different mails here and there. There might me some mission functions
> but I
> > > tried to make the whole consisted and documented. You will see that I
> have
> > > included both Global and MList modules, since MList seems to be
> approved,
> > > and Global-like used by several people here.
> >
> > Looks great.
> >
> > Can we rename MList to something more descriptive, such as List_Mutable?
> 
> I don't think so...
> Because lots of people ( including me ) are not actually opening the List
> module for example, and are using the fully qualified namespace "List.iter"
> to call functions. And after several times List_Mutable.iter is getting
> really verbose ( by the way that seems to be the caml team opinion as well
> since we have Hashtbl and not Hashtable module )

Well, Hashtbl is at least understandable what it is, shortening Mutable to
M is not.

And I wouldn't necessarily read into the ocaml team's opinion as well that
this amount of name shortening is good.  I would ask one of the main team
to back this claim.

If you use a particular name enough, then you could always do

    let miter = List_Mutable.iter

in your code.  So this gets your short names and gets me my long names.

I'm concerned that when COAN gets going, there's going to be name collisions
and choosing very short names will lead to collisions later on.

> > I think this would be relevant and consistent with other module
> distributions,
> > such as different XML parsing modules that would all be named with an XML*
> > prefix.
> 
> I think that MList is understandable enough for the average user.

Not claiming to be an average user :)  (Most Ocaml users probably aren't)
It wasn't for me.  In the week that MList was first discussed and when I
got around to looking at ExtLib, I had already forgotten what MList meant.

Best,
Blair

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

Re: [Ocaml-lib-devel] ExtLib v0.1

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

> Good suggestions.
>
> Another issue: I see (at least) two philosophies of exception naming.
>
> (1) The standard library only defines a few, and uses string arguments (to
> Failure and Invalid_argument) for specifics.
>
> (2) Nicolas's collection uses more numerous and specific exceptions:
>     Invalid_index
>     Invalid_string
>     No_such_element
>     ...
>
> I guess I'm used to the first approach, and the generality hasn't been
> a problem.  I've almost always been able to write something like
>     try ... with Failure _ -> ...
> and often just
>     try ... with _ -> ...
> rather than being more specific.  What has been the experience of
> others on this list?

We have already been discussing about that ( see the list archives ).
The probleme here is that you cannot enclose a large blocs of code within
try...with because catching Failure _ or even worst _ can be a very bad
thing. So most of the time I suppose you're doing something like :

let i = (try int_of_string s with _ -> raise MyException) in
....

and then MyException is catched by the up/calling function.  This would be
easier to have int_of_string directly raising your exception. Exceptions are
made to propagate, and Failure / Invalid_arguments are good for either
immediate catching or no-catching at all .

Nicolas Cannasse

Re: [Ocaml-lib-devel] ExtPervasives

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

>     The name ExtPervasives is misleading, because
> there functions are not "pervasive" in the truest sense,
> however the name does fit with the pattern Ext+OCaml core
> library name.

ExtStd is perhaps a better name

> (* SML-like names; other have suggested alternates:
>    handling 'a options w/o match cases *)
> val val_of : 'a option -> 'a
> val is_some : 'a option -> bool

I moved theses as well some functions sent previously by Olivier into a new
module "Option"

module Option :
  sig
 val may : ('a -> unit) -> 'a option -> unit
 val map : ('a -> 'b) -> 'a option -> 'b option
 val default : 'a -> 'a option -> 'a
 val is_some : 'a option -> bool
 val is_none : 'a option -> bool
  end

> val string_of_bool : bool -> string

this one already exists :)

> val print_bool : bool -> unit
> val prerr_bool : bool -> unit

agree.
( When I agree and when it seems obvious that people will also agree, I'm
automaticaly adding it to my local ExtLib file , and then later I 'll review
it to do some commenting and renaming )

> val output_int : out_channel -> int -> unit
> val output_float : out_channel -> float -> unit
> ...etc for basic types...

Too much verbose I think. Since most of the time you're printing mixed kind
of values, fprintf is the best choice.
I wouldn't like to promote such a programming style

>     Also, although I don't have this, what do people think about:
>
> val input_int : in_channel -> int
> val input_float : in_channel -> float
> val input_string : in_channel -> string
>
>     Which would have similar semantics to the C++ ">>" operators:
> whitespace delimits tokens, but is otherwise ignored, and line
> breaks are just another whitespace delimiter.

Same remark : use Scanf module
... or xml :)

Nicolas Cannasse

Re: [Ocaml-lib-devel] ExtLib v0.1

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

> I don't know how other people feel, but to me, the short names in
> String (ftos, stoi, stof) look very ugly.

I agree :)

> String.to_float, String.to_int, and String.to_float seem much better,
> and more consistent with the choices in the standard library.

Perhaps, but don't forget to add the Ext in front.
It's important because will users really write :  ExtString.to_float or
prefer to open ExtString ( and in this case usage of to_float without
namespace is meaningless ) and perhaps then for full qualified names we
could just name the modules EString, EHashtbl or maybe XString, XHashtbl,
etc... for fully qualified easy path access.

> An Int module with things like Int.of_string = int_of_string also
> sounds like a good idea, I'm tired of moving between Int32.t's and
> int's and having to change all sorts of functions.

Agree
If you're willing to write it fully ( MLI spec + doc + impl )....

Nicolas Cannasse

Re: [Ocaml-lib-devel] ExtLib v0.1o

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

> > Hi list
> >
> > Here's most of the functions ( sorted by module ) that I been gathered
from
> > different mails here and there. There might me some mission functions
but I
> > tried to make the whole consisted and documented. You will see that I
have
> > included both Global and MList modules, since MList seems to be
approved,
> > and Global-like used by several people here.
>
> Looks great.
>
> Can we rename MList to something more descriptive, such as List_Mutable?

I don't think so...
Because lots of people ( including me ) are not actually opening the List
module for example, and are using the fully qualified namespace "List.iter"
to call functions. And after several times List_Mutable.iter is getting
really verbose ( by the way that seems to be the caml team opinion as well
since we have Hashtbl and not Hashtable module )

> I'd prefer to see the object type first, such as List, followed by a
object
> qualifier, in this case Mutable.  So all Lists would begin with List*.
This
> would make module sorting and searching easier in COAN.

Uh ? COAN is still far from being done. Trying to figure out - and to
resolve - possible problems of the posesible intregration of ExtLib into
COAN seem counterproductive.

> I think this would be relevant and consistent with other module
distributions,
> such as different XML parsing modules that would all be named with an XML*
> prefix.

I think that MList is understandable enough for the average user. BTW future
XML documentation will of course include a fully qualified name such as
"Mutable List".

Nicolas Cannasse

[Ocaml-lib-devel] other missing functions

[Stefano Z. <za...@bo...>]

On Thu, Feb 27, 2003 at 02:51:58PM +0100, Stefano Zacchiroli wrote:
> > That would help. Thanks.

I've dug a bit more on some old ocaml sources and I've found some
additional functions that IMO should be included in the standard
library:

  (* find functions on arrays *)
- val Array.exists: ('a -> bool) -> 'a array -> bool
- val Array.for_all: ('a -> bool) -> 'a array -> bool
- val Array.find: ('a -> bool) -> 'a array -> 'a

  (* rotations on arrays and lists, step defaults to 1 *)
- val Array.lrotate: ?step:int -> 'a array -> unit
- val Array.rrotate: ?step:int -> 'a array -> unit
- val List.lrotate: ?step:int -> 'a list -> 'a list
- val List.rrotate: ?step:int -> 'a list -> 'a list

Probably all functions added to the Array module should also be added to
the Bigarray one, but I've never used it ...

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

[Ocaml-lib-devel] other missing functions

[Stefano Z. <za...@bo...>]

I've dug a bit more in some old ocaml sources and I've found some
additional functions that IMO are worth while to be inserted in the
standard library:

  (* find functions on arrays, similar to List's *)
val Array.exists: ('a -> bool) -> 'a array -> bool
val Array.for_all: ('a -> bool) -> 'a array -> bool
val Array.find: ('a -> bool) -> 'a array -> 'a

  (* rotations on lists and arrays, step defaults to 1 *)
val Array.lrotate: ?step:int -> 'a array -> 'a array
val Array.rrotate: ?step:int -> 'a array -> 'a array
val List.lrotate: ?step:int -> 'a list -> 'a list
val List.rrotate: ?step:int -> 'a list -> 'a list

Hope this helps.
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

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

[Stefano Z. <za...@bo...>]

On Fri, Feb 28, 2003 at 07:47:34PM -0500, Manos Renieris wrote:
> Of course, that means that we need the equivalent iter, map, and fold
> in Stream, like
>     val fold_left : ('a -> 'b -> 'a) -> 'a -> 'b Stream.t -> 'a
>     val map : ('a -> 'b) -> 'a Stream.t -> 'b Stream.t

Those functions could be useful also by themselves and IMO should be
added to the Stream module.

BTW the Stream.map function simplest implementation is:

  let map f s = Stream.from (fun _ -> Some (f (next s)))

anyway using such an implementation you will get a stream that couldn't
be mixed with "normal" streams (i.e. streams not built using
Stream.from), this can be ok, but should be definitely mentioned.

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

Re: [Ocaml-lib-devel] ExtLib v0.1

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

Nicolas Cannasse wrote:
> 
> Hi list
> 
> Here's most of the functions ( sorted by module ) that I been gathered from
> different mails here and there. There might me some mission functions but I
> tried to make the whole consisted and documented. You will see that I have
> included both Global and MList modules, since MList seems to be approved,
> and Global-like used by several people here.

Looks great.

Can we rename MList to something more descriptive, such as List_Mutable?

I'd prefer to see the object type first, such as List, followed by a object
qualifier, in this case Mutable.  So all Lists would begin with List*.  This
would make module sorting and searching easier in COAN.

I think this would be relevant and consistent with other module distributions,
such as different XML parsing modules that would all be named with an XML*
prefix.

Best,
Blair

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

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

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

Brian Hurt wrote:
> 
> 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.

I can offer a Subversion repository on my own box.  I currently host my
own open source packages there.  It's on a DSL, so it isn't the fastest
connection, but it works pretty well.

    http://svn.orcaware.com/

and

    http://svn.orcaware.com:8000/repos/

for the top of the repository.

Subversion is the next versioning system designed as a replacement for
CVS.  See

http://www.orcaware.com/svn/Subversion-Blair_Zajac.ppt

for a PPT on the improvements that Subversion offers.

Best,
Blair

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

Re: [Ocaml-lib-devel] ExtLib v0.1

[Michal M. <mal...@pl...>]

On Fri, Feb 28, 2003 at 07:54:29PM -0500, Manos Renieris wrote:
> I don't know how other people feel, but to me, the short names in
> String (ftos, stoi, stof) look very ugly.
> 
> String.to_float, String.to_int, and String.to_float seem much better,
> and more consistent with the choices in the standard library.
> An Int module with things like Int.of_string = int_of_string also 
> sounds like a good idea, I'm tired of moving between Int32.t's and
> int's and having to change all sorts of functions.

Int module could be also useful for Map.Make.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

Re: [Ocaml-lib-devel] ExtPervasives

[Michal M. <mal...@pl...>]

On Fri, Feb 28, 2003 at 06:19:21PM +0100, Amit Dubey wrote:
> 	val output_int : out_channel -> int -> unit

It's like: 

	let output_int c i = Printf.fprintf c "%d" i 

? Or maybe outputs binary representation? And output_float outputs with
what precision?

> val input_int : in_channel -> int

I used this much writing code for programming contest:

	let input_int c = Scanf.fscanf c " %d" (fun x -> x)

> val input_float : in_channel -> float
> val input_string : in_channel -> string

Didn't use these, but they can be probably usable in similar
environments.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

Re: [Ocaml-lib-devel] ExtLib v0.1

[Eric C. C. <ec...@cm...>]

On Fri, Feb 28, 2003 at 07:54:29PM -0500, Manos Renieris wrote:
> I don't know how other people feel, but to me, the short names in
> String (ftos, stoi, stof) look very ugly.

I agree.

> String.to_float, String.to_int, and String.to_float seem much better,
> and more consistent with the choices in the standard library.
> An Int module with things like Int.of_string = int_of_string also 
> sounds like a good idea, I'm tired of moving between Int32.t's and
> int's and having to change all sorts of functions.

Good suggestions.

Another issue: I see (at least) two philosophies of exception naming.

(1) The standard library only defines a few, and uses string arguments (to
Failure and Invalid_argument) for specifics.

(2) Nicolas's collection uses more numerous and specific exceptions:
    Invalid_index
    Invalid_string
    No_such_element
    ...

I guess I'm used to the first approach, and the generality hasn't been
a problem.  I've almost always been able to write something like
    try ... with Failure _ -> ...
and often just
    try ... with _ -> ...
rather than being more specific.  What has been the experience of
others on this list?

-- 
Eric C. Cooper          e c c @ c m u . e d u

Re: [Ocaml-lib-devel] ExtLib v0.1

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

I don't know how other people feel, but to me, the short names in
String (ftos, stoi, stof) look very ugly.

String.to_float, String.to_int, and String.to_float seem much better,
and more consistent with the choices in the standard library.
An Int module with things like Int.of_string = int_of_string also 
sounds like a good idea, I'm tired of moving between Int32.t's and
int's and having to change all sorts of functions.

-- Manos

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

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

On Fri, Feb 28, 2003 at 12:38:12PM +0900, Nicolas Cannasse wrote:
> >   (* fold left on file lines (without trailing newline), I don't know in
> >   which module this functions should go, maybe Sys? *)
> > - val fold_file : ('a -> string -> 'a) -> 'a -> string -> 'a
> >   (* iter on file lines *)
> > - val iter_file : (string -> unit) -> string -> unit
> 
> perhaps :
> 
> val iter_in : (string -> unit) -> in_channel -> unit
> val map_in : (string -> 'a) -> in_channel -> 'a list
> val fold_in : ('a -> string -> 'a) -> 'a -> in_channel -> 'a

> 
> are better so it can work on many kind of descriptors and does not have to
> handle the "file not found" problems
> 
> I propose also :
> 
> val read_lines : in_channel -> string list
> val read_all : in_channel -> string
> 
> that returns all the contents ( up to End_of_file )

I think that all of those can be done much better with Streams
(the streams that are in the Stream standard module).
Something like
    Stream.of_lines (ic:in_channel) : string Stream.t
Of course, that means that we need the equivalent iter, map, and fold
in Stream, like
    val fold_left : ('a -> 'b -> 'a) -> 'a -> 'b Stream.t -> 'a
    val map : ('a -> 'b) -> 'a Stream.t -> 'b Stream.t

-- Manos

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

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

On Fri, 28 Feb 2003, Nicolas Cannasse wrote:

(attribution lost)

> >   (* like perl's chomp function, remove trailing newline characters *)
> > - val String.chomp : string -> string
> 
> Uhm, why not, but this need some discuss on implementation since newline is
> "\r\n" under windows and "\n" under *nix....

I'd recognize either:

let chomp s = 
    let leAn = String.length s in
    if ((len > 0) && (s.[len - 1] == '\n')) then
        if ((len > 1) && (s.[len - 2] == '\r')) then
            String.sub s 0 (len - 2)
        else
            String.sub s 0 (len - 1)
    else
        s
;;

Just IMHO.

Brian

Re: [Ocaml-lib-devel] Mutable List

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

Hello everyone.  Sorry for the silence- I had a cold.

On Wed, 26 Feb 2003, Michal Moskal wrote:

> On Wed, Feb 26, 2003 at 11:01:04AM +0900, Nicolas Cannasse wrote:
> >  val copy : 'a t -> 'a t -> unit
> 
> Ordering of arguments is copy dst src? I thought copy src dst, but...

This is one of those things which, IMHO, should be standardized- all 
library functions do it the same way.  I can see it woring either way:
copy src1 src2 src3 ... dst
copy dst src1 src2 src3 ...
both work.  I just want to pick *one* and stick with it.

Brian

[Ocaml-lib-devel] ExtPervasives

[Amit D. <ad...@Co...>]

    I was about to reply about extentions to "Global", then
I realized that it was not quite was I thought it was...
I had been expecting a new pervasives, ooops :)

    The name ExtPervasives is misleading, because
there functions are not "pervasive" in the truest sense,
however the name does fit with the pattern Ext+OCaml core
library name.

    I didn't document the obvious functions.

module type ExtPervasives =
    sig

	(* SML-like names; other have suggested alternates:
	   handling 'a options w/o match cases *)
	val val_of : 'a option -> 'a
	val is_some : 'a option -> bool

	val string_of_bool : bool -> string
	val print_bool : bool -> unit
	val prerr_bool : bool -> unit

	val output_int : out_channel -> int -> unit
	val output_float : out_channel -> float -> unit
	...etc for basic types...

    end

    Also, although I don't have this, what do people think about:

val input_int : in_channel -> int
val input_float : in_channel -> float
val input_string : in_channel -> string

    Which would have similar semantics to the C++ ">>" operators:
whitespace delimits tokens, but is otherwise ignored, and line
breaks are just another whitespace delimiter.


    -Amit

[Ocaml-lib-devel] ExtLib 0.1 ExtHash

[Amit D. <ad...@Co...>]

> (* ****** Module ExtHash **** *)
> 
> module ExtHash :
>   sig
> 
> 	(* return all the keys of an Hashtable
> 	   if the key is several time in the Hashtable, the list will
> 	   contain it that many times *)
> 	val keys : ('a,'b) Hashtbl.t -> 'a list
> 
> 	(* return all the values of an Hashtable *)
> 	val values : ('a,'b) Hashtbl.t -> 'b list
> 
> 	(* remove all bindings for the given key *)
> 	val remove_all : ('a,'b) Hashtbl.t -> 'a -> unit
> 
>   end

    I use hashtables extensively in my work, and there are
two functions that I find invaluable.  (The names, I admit,
might be stupid :)

(* return the element bound to the given key; if no such
   element exists, return a default value *)

val find_always : ('a,'b) Hashtbl.t -> ~key : 'a -> ~default : 'b -> 'b
val safe_find (* alternate name *)

(* replace an old binding with a new one whose value depends
   on the old one.  If no previous binding exists, use a default
   value
 *)

val update :
    ('a, 'b) Hastbl.t ->
    ~key : 'a ->
    ~default : 'b ->
    ('b -> 'b) -> unit

    My primary use of hashtables is to store sparse arrays, which
assume a value of `0.0' anywhere there is currently no binding.
I'm not sure this is useful to people who don't use hashtables
this way.

    -Amit