ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] Idea with ExtList.fold_right

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

> So do a length of the list and pick the "right" algorithm for the job.
> The length should be limited- once we know the list is too long, we can
> exit (we don't need the full length).  This gives rise to the following
> code:
[...]
> Thoughts?  Comments?  Benchmarks?

The problem here is that the "good number" will be good for some
applications but not good for other ones.
For example if one of my program have a bunch of *exactly* 1000 elements
list, then I'm spending a lot of time in counting elements... for nothing.
One possibility is to have that counter really be dynamic , se when we
return false we divide the counter by two, and when true we it multiply by
1.5 or something with of course reasonable bounds. Looks a little like TCP
:-)
But even like this i'm not very satisfied...

Actually , here's the problem : why do people need fold_right ? ( means :
why don't they use fold_left ? )
Answer : because most of the time they want to build a list in the same
order as the input list.

Ok, so let's provide them a "list only" version of fold_right ( ExtList.fold
? ) that will do the job in a tail-rec way using internals set_cdr to
construct the list in the user-wanted way. This of course does not cover all
the cases, but should be enough to preserve speed where it is needed (btw
enums should be even better for this kind of things ^^;) . The difference of
this fold is that we are iterating from left_to_right but I don't think that
a lot of users actually wants to do so.

Nicolas Cannasse

Re: [Ocaml-lib-devel] Idea with ExtList.fold_right

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

On Sat, 14 Jun 2003, John Max Skaller wrote:

> i don't want you counting my lists :-)

What is so evil about doing a List.length?  Especially in this case, where 
I hard cap the computational cost- as all I need to answer is if the 
length less than some constant.  So, for short lists (for some suitably 
wimbly definition of short) doing a list length is cheap.  For long lists, 
the length function short circuits out without doing a full count.  Maybe 
I should have made max smaller- 100 say, instead of 1000.  *Especially* 
since we're about to do an O(N) fold_right on the list anyways.

Now, mind you, there *are* reasons why my code may not be the most 
optimum.  Including:

- at some arbitrary point the algorithm trades off heap space for stack 
space, meaning it's hard to estimate how much of each you'll need.

- there is some performance benefit to be gained if you already know what 
the right routine to call is.

> 
> I know which routine I need from context often.
> So provide:
> 
> 	fold_right
> 	rev_fold_right

Or possibly even three- recursive, reversing, and sense-selecting.  

Brian

Re: [Ocaml-lib-devel] Version 1.0?

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

> 
> 
> My opinion: version 1.0 should be a source tarbar.  If we wait until we're
> all things to all people, we'll never release.  A lot of the packaging
> should be done external to the build process anyways.
> 
> Now, to a more relevent question: what's left that needs to be documented?
> 
> Brian

    Hi all,

    I made a couple additions to the in-code Ocamldoc documentation.  The biggies
that are left are: RefList and anything to do with Enum's.  There are bits and
pieces missing here and there...

    When I get the chance, I'll put the new htdocs on the webpage.

    -Amit

Re: [Ocaml-lib-devel] Idea with ExtList.fold_right

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

Brian Hurt wrote:

> Just had an idea for ExtList.fold_right.  Ok, there are basically two 
> different possible implementations: the non-tail-recursive version:
> 
> let rec fold_right f lst init =
>     match lst with
>         | [] -> init
>         | h :: t -> f h (fold_right f t init)
> 
> And the tail-recursive, list reversing version:
> 
> let fold_right f lst init =
>     let rec loop l accu =
>         match l with 
>             [] -> accu
>             | h :: t -> loop t (f h accu)
>     in
>     loop (List.rev lst) init
>     
> 
> The first one is faster for short lists, but stack overflows on long 
> lists.  The second one never overflows, but is slower for short lists.
> 
> So do a length of the list and pick the "right" algorithm for the job.  
> The length should be limited- once we know the list is too long, we can 
> exit (we don't need the full length).  This gives rise to the following 
> code:
> 
> let fold_right f lst init =
>     let max = 1000 in
>     let rec toolong len = function
>         | [] -> false
>         | h :: t -> if len >= max then true else toolong (len + 1) t
>     and revloop accu = function
>         | [] -> accu
>         | h :: t -> revloop (f h accu) t
>     and ntrloop = function
>         | [] -> init
>         | h :: t -> f h (ntrloop t)
>     in
>     if toolong 0 lst then
>         revloop init (List.rev lst)
>     else
>         ntrloop lst
> 
> Thoughts?  Comments?  Benchmarks?

i don't want you counting my lists :-)

I know which routine I need from context often.
So provide:

	fold_right
	rev_fold_right

The fact is, I'll often chose rev_fold_right
because I WANT the list reversed.

I suspect the way to handle a dynamic trade off is:

	fold_right_dynamic estimate f lst init

where 'estimate' is provided by the client.
you don't count the list and decide, you decide based
on the client's estimate. The client can then:

	a) count the list, or otherwise create
	an estimate

	b) curry the function on the estimate

Example: in my Felix compiler I have lists of function
parameters. Well, I know they're short, i don't have to
count them, and if someone writs a function with
2000 parameters, well, I just don't care if there's
a minor slow down :-)

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

Re: [Ocaml-lib-devel] Version 1.0?

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

My opinion: version 1.0 should be a source tarbar.  If we wait until we're
all things to all people, we'll never release.  A lot of the packaging
should be done external to the build process anyways.

Now, to a more relevent question: what's left that needs to be documented?

Brian

Re: [Ocaml-lib-devel] Version 1.0?

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

On Thu, Jun 12, 2003 at 02:54:45PM +0900, Nicolas Cannasse wrote:
> > I tried to do that once and users hated it :-)
> > They wanted a plain old tarball. Still, software like Internet
> > Explorer and Redhat Linux use this idea, but I suspect
> > it would be more useful if it could update multiple packages,
> > not just Extlib.
> [...]
> > You can make an executable which is put in, say
> [...]
> > extlib --help --version --test
> 
> This is directly putting us back into the COAN thread.
> Multiple packages, dependencies, patches, install , compile , link , update.
> A lot of things to do , in a portable way.
> 
> Right now some people from the Caml team and around have been talking about
> such a tool. I might start implementing such a thing quite soon, based on
> the statement they made and on several long talks I already have about it
> with Jacques Garrigue. I'll keep informed people on this list of further
> advances.

When designing such tool, take into account that lots of ocaml users out
there is using rpms and debs with ocaml related stuff. Installing
packages from sources, and managing it using specialized tools is often
not an option.

So please separate software installation from querying compiler options
for given package and the like. For example create few conceptually
simple tools, one can be pkgconfig look-alike, other rpm (package
manager that can handle package installation and removal) with limited
functionality, and yet another apt-get (tool to automagically fetch deps
for given package) with recompilation support.

As a side-note: I really regret pkgconfig didn't come out earlier, since
it allows to get rid of all (or almost all) autoconfig stuff, but only
if your required packages support it.

Anyhow:

[malekith@roke ~]$ ls /usr/lib/pkgconfig|wc -l
     79
[malekith@roke ~]$ 
     
It got quite popular, not only for gnome-related stuff. I believe
one of sources of its success was conceptual simplicity. All you need to
support pkgconfig, is to put simple foo.pc file in /usr/lib/pkgconfig.

Example:

#v+
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=/usr/include/alsa

Name: alsa
Description: Advanced Linux Sound Architecture (ALSA) - Library
Version: 0.9.3
Requires: 
Libs: -L${libdir} -lasound -lm -ldl -lpthread
Cflags: -I${includedir}
#v-

Of course for ocaml we would need somewhat different lines, but you get
the idea.

And yes, there is findlib already. But it's far too complex for my
taste -- it tries to handle too much.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::::: Wroclaw University, CS Dept : {E-,w}-- {b++,e}>+++ h

[Ocaml-lib-devel] Idea with ExtList.fold_right

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

Just had an idea for ExtList.fold_right.  Ok, there are basically two 
different possible implementations: the non-tail-recursive version:

let rec fold_right f lst init =
    match lst with
        | [] -> init
        | h :: t -> f h (fold_right f t init)

And the tail-recursive, list reversing version:

let fold_right f lst init =
    let rec loop l accu =
        match l with 
            [] -> accu
            | h :: t -> loop t (f h accu)
    in
    loop (List.rev lst) init
    

The first one is faster for short lists, but stack overflows on long 
lists.  The second one never overflows, but is slower for short lists.

So do a length of the list and pick the "right" algorithm for the job.  
The length should be limited- once we know the list is too long, we can 
exit (we don't need the full length).  This gives rise to the following 
code:

let fold_right f lst init =
    let max = 1000 in
    let rec toolong len = function
        | [] -> false
        | h :: t -> if len >= max then true else toolong (len + 1) t
    and revloop accu = function
        | [] -> accu
        | h :: t -> revloop (f h accu) t
    and ntrloop = function
        | [] -> init
        | h :: t -> f h (ntrloop t)
    in
    if toolong 0 lst then
        revloop init (List.rev lst)
    else
        ntrloop lst

Thoughts?  Comments?  Benchmarks?

Brian

[Ocaml-lib-devel] Psqueue API change

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

Psqueue.query (imprecise) should return 'a option.  Instead of the current
kludge.

Checkin in a few minutes.

Brian

Re: [Ocaml-lib-devel] Version 1.0?

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

John Max Skaller wrote:
> 
> Blair Zajac wrote:
> 
> > Instead of reinventing the wheel here, how about using pkg-config.  It
> > handles this kind of stuff and used by a large number of packages:
> >
> > % ls /usr/lib/pkgconfig/
> 
> Wow. I got a /usr/lib/pkgconfig directory on my box.
> Never heard of it before.
> Unfortunately, I don't seem to have the tool itself.
> 
> So someone (like me) that wanted to use Felix would not
> 
> only have to download Python, Interscript, and Ocaml,
> but also ExtLib and pkgconfig ..

Which OS are you using?

Best,
Blair

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

Re: [Ocaml-lib-devel] Version 1.0?

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

> I tried to do that once and users hated it :-)
> They wanted a plain old tarball. Still, software like Internet
> Explorer and Redhat Linux use this idea, but I suspect
> it would be more useful if it could update multiple packages,
> not just Extlib.
[...]
> You can make an executable which is put in, say
[...]
> extlib --help --version --test

This is directly putting us back into the COAN thread.
Multiple packages, dependencies, patches, install , compile , link , update.
A lot of things to do , in a portable way.

Right now some people from the Caml team and around have been talking about
such a tool. I might start implementing such a thing quite soon, based on
the statement they made and on several long talks I already have about it
with Jacques Garrigue. I'll keep informed people on this list of further
advances.

Nicolas Cannasse

Re: [Ocaml-lib-devel] Version 1.0?

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

Blair Zajac wrote:

> Instead of reinventing the wheel here, how about using pkg-config.  It
> handles this kind of stuff and used by a large number of packages:
> 
> % ls /usr/lib/pkgconfig/


Wow. I got a /usr/lib/pkgconfig directory on my box.
Never heard of it before.
Unfortunately, I don't seem to have the tool itself.

So someone (like me) that wanted to use Felix would not

only have to download Python, Interscript, and Ocaml,
but also ExtLib and pkgconfig ..

Hmmm ..


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

Re: [Ocaml-lib-devel] Re: OCamlMakefile

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

> > OCamlMakefile is doing less then ocamake, and in an non portable way.
> > If you read the README , you will see : "get and install Ocamake from
> > http://tech.motion-twin.com"
> 
> Nicolas,
> 
>   Any chance you could change ocamake to exit with a non-zero status
>   when it fails to build something?  In the "failed to build
>   dependencies" mode, for me at least, it exits with zero status.

Funny , I actually added this yesterday in my local version.
I'll update the online version asap.

Nicolas Cannasse

[Ocaml-lib-devel] Re: OCamlMakefile

[Alan P. <ap...@re...>]

In article <00d301c33088$3e580ff0$2713f9ca@WARP>, Nicolas Cannasse wrote:
> 
> OCamlMakefile is doing less then ocamake, and in an non portable way.
> If you read the README , you will see : "get and install Ocamake from
> http://tech.motion-twin.com"

Nicolas,

  Any chance you could change ocamake to exit with a non-zero status
  when it fails to build something?  In the "failed to build
  dependencies" mode, for me at least, it exits with zero status.

    Alan

Re: [Ocaml-lib-devel] OCamlMakefile

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

>     I don't have the ocamake utility, so I couldn't build
> anything ;)  I noticed on the list someone suggested a move
> to OCamlMakefile.  I hope no one minds, but I've made this
> change.  I've also added a few tidbits of ocamldoc comments.
> Is it OK if I commit these changes?

About documentation, yes fell free to commit of course !
As for OCamlMakefile , please don't !
OCamlMakefile is doing less then ocamake, and in an non portable way.
If you read the README , you will see : "get and install Ocamake from
http://tech.motion-twin.com"

Nicolas Cannasse

Re: [Ocaml-lib-devel] Version 1.0?

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

John Max Skaller wrote:
> 
> Nicolas Cannasse wrote:
> 
> > I agree on this one . Modern software development and Internet are enabling
> > a quick bug reporting/fix and then users only have to update their version.
> > About this "update" and installation-made-easy of the ExtLib, I was thinking
> > writing a small and simple OCaml program that will check and download the
> > last extlib version , compile using ocamake (I think perhaps we should then
> > put ocamake in the ExtLib) and install it in  'ocamlc -where'/extlib .
> 
> I tried to do that once and users hated it :-)
> They wanted a plain old tarball. Still, software like Internet
> Explorer and Redhat Linux use this idea, but I suspect
> it would be more useful if it could update multiple packages,
> not just Extlib.

I agree a tarball release should be available.

> > I would like to have some comments from Unix users to know how we can make the
> > user being able to choose the install directory and still have a nice and
> > portable way of retreiving the install dir (needed by Makefile of program
> > using ExtLib at linking time).
> 
> You can make an executable which is put in, say
> 
>         /usr/local/bin
> 
> or
> 
>         ~/bin
> 
> extlib
> 
> which prints the install dir so people can write:
> 
>         ocamlc -I`extlib`
> 
> and add some options:
> 
>         extlib --help --version --test
> 
> it would also be tricky to have
> 
>         man extlib
> 
> tell where the installation went.

Instead of reinventing the wheel here, how about using pkg-config.  It
handles this kind of stuff and used by a large number of packages:

% ls /usr/lib/pkgconfig/
fontconfig.pc           gnome-python-2.0.pc*    libxml-2.0.pc
gconfgtk.pc             gobject-2.0.pc          libxml.pc
gconf.pc                gthread-2.0.pc          libxslt.pc
gdk.pc                  gthread.pc              openssl.pc*
glib-2.0.pc             gtk+.pc                 ORBit.pc
glib.pc                 libIDL.pc               xcursor.pc
gmodule-2.0.pc          libmetacity-private.pc  xft.pc
gmodule.pc              libnautilus.pc
gnome-mime-data-2.0.pc  libpng12.pc

You can query arbitrary settings for your package:

% pkg-config --help
Usage: pkg-config [OPTION...]
  --version                                      output version of pkg-config
  --modversion                                   output version for package
  --atleast-pkgconfig-version=VERSION            require given version of
                                                 pkg-config
  --libs                                         output all linker flags
  --libs-only-l                                  output -l flags
  --libs-only-L                                  output -L flags
  --cflags                                       output all pre-processor and
                                                 compiler flags
  --cflags-only-I                                output -I flags
  --variable=VARIABLENAME                        get the value of a variable
  --define-variable=VARIABLENAME=VARIABLEVALUE   set the value of a variable
  --exists                                       return 0 if the module(s)
                                                 exist
  --uninstalled                                  return 0 if the uninstalled
                                                 version of one or more
                                                 module(s) or their
                                                 dependencies will be used
  --atleast-version=VERSION                      return 0 if the module is at
                                                 least version VERSION
  --exact-version=VERSION                        return 0 if the module is at
                                                 exactly version VERSION
  --max-version=VERSION                          return 0 if the module is at
                                                 no newer than version VERSION
  --list-all                                     list all known packages
  --debug                                        show verbose debug information
  --print-errors                                 show verbose information
                                                 about missing or conflicting
                                                 packages
  --silence-errors                               show verbose information
                                                 about missing or conflicting
                                                 packages
  --errors-to-stdout                             print errors from
                                                 --print-errors to stdout not
                                                 stderr

Help options
  -?, --help                                     Show this help message
  --usage                                        Display brief usage message

Best,
Blair

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

[Ocaml-lib-devel] OCamlMakefile

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

    Hi everyone,

    I must apologize for not (yet) submitting any code, as
I've been a bit busy.  I did, however, just do an update with
the intention of adding more documentation (as this was
recommended as an important goal of reaching 1.0 quickly ;)

    I don't have the ocamake utility, so I couldn't build
anything ;)  I noticed on the list someone suggested a move
to OCamlMakefile.  I hope no one minds, but I've made this
change.  I've also added a few tidbits of ocamldoc comments.
Is it OK if I commit these changes?

    -Amit

Re: [Ocaml-lib-devel] Version 1.0?

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

Nicolas Cannasse wrote:


> I agree on this one . Modern software development and Internet are enabling
> a quick bug reporting/fix and then users only have to update their version.
> About this "update" and installation-made-easy of the ExtLib, I was thinking
> writing a small and simple OCaml program that will check and download the
> last extlib version , compile using ocamake (I think perhaps we should then
> put ocamake in the ExtLib) and install it in  'ocamlc -where'/extlib . 


I tried to do that once and users hated it :-)
They wanted a plain old tarball. Still, software like Internet
Explorer and Redhat Linux use this idea, but I suspect
it would be more useful if it could update multiple packages,
not just Extlib.

> I would like to have some comments from Unix users to know how we can make the
> user being able to choose the install directory and still have a nice and
> portable way of retreiving the install dir (needed by Makefile of program
> using ExtLib at linking time).


You can make an executable which is put in, say


	/usr/local/bin

or

	~/bin

extlib

which prints the install dir so people can write:

	ocamlc -I`extlib`

and add some options:

	extlib --help --version --test

it would also be tricky to have

	man extlib

tell where the installation went.

 
> Releasing with bugs is one point : theses can be fixed later.
> But releasing without any correct documentation IS a mistake.


	I agree.


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

Re: [Ocaml-lib-devel] Version 1.0?

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

Brian Hurt wrote:

> On Wed, 11 Jun 2003, John Max Skaller wrote:


> I only know of one API question at this point: things that might change
> (go away): and that's precise/imprecise actions in psqueue.  Currently
> there are two sets of operations: find, adjust, add, and remove, which
> throw an exception on "unexpected" conditions (adding a key that already
> exists, removing a key which doesn't, etc), and query, update, insert, and
> delete, which do something "intelligent" in those costs (adding a key that
> already exists becomes an update, removing a key that doesn't exist does
> nothing, etc).  Now, my preference would be to pick one of the two sets
> and run with it- but I don't know which one.  Feedback would be
> appreciated here.


I'm afraid my comments won't help much .. but I'll make them anyhow.


I use Hashtbl, and until recently only the basic functions.
Now, sometimes, it does more than I want, for example, I've never use
the pushdown stack of entries feature. So for me, the 'add' function
is actually a pain, since I have to first check if a key is present
to avoid duplicates. Similarly, sometimes I just want to either
add or replace, and I had to write code to do that.

Since I found 'replace' was added, I'm using that now.
Its equivalent to 'add if not present otherwise update',
which is easy enough to code, but I get a feeling the built-in
update is more efficient, and I can check its semantics in the manual,
rather than search my own code.

So .. I wouldn't do without the raw primitives: they're the routines
which form a basis, and which are expected to be fast. But some
of the composite routines are also useful and perhaps more likely
to be what is needed in many cases.

So I'd probably include *both* the axioms and the theorems,
without going overboard: include the extra stuff if it's likely to
be heavily used OR allows for more efficient processing OR
would be hard to code. Hmmm .. meaning: enrich the basic
interface but not *too* much. You can always add in the extra
routines later if someone complains, but you want the interface
to be ready to use without needing a whole lot of client
written auxilliaries.

Which I think leaves you just as uncertain as before :-)

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

Re: [Ocaml-lib-devel] Version 1.0?

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

> And plenty of problems with Ocaml itself.
> And there are many that you won't even find yourself:
> you need users to help you both find problems,
> and also to prioritorise them.

I agree on this one . Modern software development and Internet are enabling
a quick bug reporting/fix and then users only have to update their version.
About this "update" and installation-made-easy of the ExtLib, I was thinking
writing a small and simple OCaml program that will check and download the
last extlib version , compile using ocamake (I think perhaps we should then
put ocamake in the ExtLib) and install it in  'ocamlc -where'/extlib . I
would like to have some comments from Unix users to know how we can make the
user being able to choose the install directory and still have a nice and
portable way of retreiving the install dir (needed by Makefile of program
using ExtLib at linking time).

> RELEASE ExtLib within one week no matter what.
>
> I want to use it! I don't CARE if its bugged,
>
> or if the interfaces aren't right yet.

Releasing with bugs is one point : theses can be fixed later.
But releasing without any correct documentation IS a mistake.
If users don't understand what's inside / how to use the version 1 , they'll
not get "ext-addicted" :-) and will simply don't use it. If you want a quick
release of ExtLib, please help with writing the documentation of existing
modules !

Nicolas Cannasse

Re: [Ocaml-lib-devel] Version 1.0?

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

On Wed, 11 Jun 2003, John Max Skaller wrote:

> One thing Guido van Rossum, the inventor of Python,
> once said to me was that all that really mattered was
> users. (Meaning, your product is good if it attracts
> a lot of users).

This I seriously agree with.  A 1.0 release would help adoption.  
Especially as it seems we do have users, or at least potiential users.

> Well, its easier for a group.
> So I vote:
> 
> RELEASE ExtLib within one week no matter what.
> 
> I want to use it! I don't CARE if its bugged,
> 
> or if the interfaces aren't right yet.

I only know of one API question at this point: things that might change
(go away): and that's precise/imprecise actions in psqueue.  Currently
there are two sets of operations: find, adjust, add, and remove, which
throw an exception on "unexpected" conditions (adding a key that already
exists, removing a key which doesn't, etc), and query, update, insert, and
delete, which do something "intelligent" in those costs (adding a key that
already exists becomes an update, removing a key that doesn't exist does
nothing, etc).  Now, my preference would be to pick one of the two sets
and run with it- but I don't know which one.  Feedback would be
appreciated here.

There are a number of functions I'd like to add (psqueue.enum for
example).  But adding functions isn't a problem (for compatibility)- it's
removing or altering existing functions.

Brian

Re: [Ocaml-lib-devel] Version 1.0?

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

Diego Olivier Fernandez Pons wrote:

>     Bonjour,
> 
> 
>>It is necessary to provide on-site documentation to what is
>>*officially* working properly, and to include that in any release.
>>
> 
> Not stating clearly what does work and what doesn't is a mistake I
> have done in Baire. I really think Jonh Max Skaller is right in this
> point and OCaml-lib should avoid doing the same mistake I did.
> 
> 
>>If you do that, it doesn't matter if the other half of the library
>>isn't ready. Release it anyhow.
>>
>>	release early, release often
>>
> 
> One of the problems is the stability of interfaces. I have broken and
> rewritten from scratch Baire several times, and I will continue doing
> so until I get it right.


I am the same with Felix. It's been around for 3-4 years, and never 

announced. But really, I think it is necessary to credit the initial
users of a package with a willingness to rewrite the code that uses
your package as you change it.

Unless of course, you are lucky, and get 100K users on the first
day :-)


> It is important to be able to do such things when you are not an
> experimented developer in the concerned field (and Baire surely is my
> first data structure library).
 
> I don't know how the Caml-lib team feels it, but I first though
> 'initial' Baire would be the only one and I realized much later there
> were a lot of wrong things in it.


So? There are a lot of things wrong with C++ too.

And plenty of problems with Ocaml itself.
And there are many that you won't even find yourself:
you need users to help you both find problems,
and also to prioritorise them.

One thing Guido van Rossum, the inventor of Python,
once said to me was that all that really mattered was
users. (Meaning, your product is good if it attracts
a lot of users).

I don't entirely agree, but he has a point.
And you won't have any users if you don't release :-)

Be willing to be caught out making a mistake.

[Arggg .. I can't release Felix yet .. its incomplete ..
its got bugs ..]

Yeah, its really hard to do, especially for an individual.

Well, its easier for a group.
So I vote:

RELEASE ExtLib within one week no matter what.

I want to use it! I don't CARE if its bugged,

or if the interfaces aren't right yet.

Thing is, I don't have any idea yet, because I haven't
tried using it, and I CANNOT make my package depend
on a CVS archive or my own private copy of the code.
[indeed, there is a licencing issue: Felix is FFAU]

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

Re: [Ocaml-lib-devel] Proposal : BinTree

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

On Tue, 10 Jun 2003, Nicolas Cannasse wrote:

> > > Here's a module proposal for adding to the ExtLib.
> > > This is a binary search tree ( module BinTree ).
> > > Operations  add, remove, find are done in Log(n) when the tree is
> optimized.
> > > This is a mutable version of the data structure.
> > >
> >
> > Is there a reason you did this as a mutable tree and not the "standard"
> > applicative version?
> 
> That's a good question. Actually is there a standard ?

"Classic" might have been a better word than Standard.

Basically,

type 'a tree_t = Void | Node of 'a tree_t * 'a * 'a tree_t
(* or whatever *)

val add : 'a tree_t -> 'a -> 'a tree_t

etc.

> List are of course applicative, Array are of course mutables, but if Sets
> are applicative , Hashtables and Stack are mutable...
> Should we provide both mutable and applicative version of every data
> structure ?

I'd say no.  We should provide the "natural" or "usefull" version.  
Defining what I mean by natural or usefull gets tricky.

The only reason I can see for stacks to be mutable in the standard library
is because the applicative version is *so* trivial to implement.  I mean:

type 'a stack = 'a list

let push s e = e :: s

let top s = List.hd s

let pop s = List.tl s

Maps are applicative, and are based upon applicative trees.  Same with
sets- also based on applicative trees.  Hashtables I could see being
mutable because they are conceptually based upon arrays- which are also
mutable.  Strings are mutable, and buffers are as well as they're
conceptually based upon strings (which are conceptually based upon arrays
of chars).  Personally, I'd have preferred nonmutable strings, but neither
here nor there.  Queues are mutable because I don't know of any sane way
to implement them applicatively.

> 
> Actually it's good sometimes to have applicative structures, it fits well
> with the functional style where you can write :
>     let l = List.map f l in
>     let l = List.filter f2 l in
>     last_call  (List.filter f3 l)
> 
> The main advandage here is being able to pass a modified data structure as
> argument to another, without actually modifiying it.
> But most of the time, the thing you want to really do is :
> 
> let l = last_call (List.filter f3 l)
> 
> Please note that here I took "filter" as sample function, because map is
> always applicative since it can change the type (BTW, we could add in-place
> map to MList) , same for fold.
> 
> IMHO, there is only few cases when people are actually using the
> "immutable" feature of a data structure, and then if you're providing
> a "copy" operation (Enum can do it for you :-) you have the same
> expression power, with shorter syntax since you don't have to rebind
> the same variable ever and ever.

There is explicitly using applicative features, and implicitly using it.  
Consider:

let foo lst =
    (* pick out just those items I want *)
    let mylst = List.filter f3 lst in 
    (* a bunch of code that uses mylst and not lst *)

Now here, from the function's perspective, lst might as well go away after 
the call to filter.  But the code calling this function might be depending 
upon lst to not be modified by foo.  So I think the applicative/functional 
aspect of Ocaml is used a lot more often than it might look it.

All of which has nothing to do with wether the tree library should be
applicative or mutable.  If the library is created mutable, then in using
it you may have side-effects.  Just like several other libraries/data
structures.

Brian

Re: [Ocaml-lib-devel] Proposal : BinTree

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

> > Here's a module proposal for adding to the ExtLib.
> > This is a binary search tree ( module BinTree ).
> > Operations  add, remove, find are done in Log(n) when the tree is
optimized.
> > This is a mutable version of the data structure.
> >
>
> Is there a reason you did this as a mutable tree and not the "standard"
> applicative version?

That's a good question. Actually is there a standard ?
List are of course applicative, Array are of course mutables, but if Sets
are applicative , Hashtables and Stack are mutable...
Should we provide both mutable and applicative version of every data
structure ?

Actually it's good sometimes to have applicative structures, it fits well
with the functional style where you can write :
    let l = List.map f l in
    let l = List.filter f2 l in
    last_call  (List.filter f3 l)

The main advandage here is being able to pass a modified data structure as
argument to another, without actually modifiying it.
But most of the time, the thing you want to really do is :

let l = last_call (List.filter f3 l)

Please note that here I took "filter" as sample function, because map is
always applicative since it can change the type (BTW, we could add in-place
map to MList) , same for fold.

IMHO, there is only few cases when people are actually using the "immutable"
feature of a data structure, and then if you're providing a "copy" operation
(Enum can do it for you :-) you have the same expression power, with shorter
syntax since you don't have to rebind the same variable ever and ever.

Nicolas Cannasse

Re: [Ocaml-lib-devel] Version 1.0?

[Diego O. F. P. <Die...@et...>]

    Bonjour,

> It is necessary to provide on-site documentation to what is
> *officially* working properly, and to include that in any release.

Not stating clearly what does work and what doesn't is a mistake I
have done in Baire. I really think Jonh Max Skaller is right in this
point and OCaml-lib should avoid doing the same mistake I did.

> If you do that, it doesn't matter if the other half of the library
> isn't ready. Release it anyhow.
>
> 	release early, release often

One of the problems is the stability of interfaces. I have broken and
rewritten from scratch Baire several times, and I will continue doing
so until I get it right.

It is important to be able to do such things when you are not an
experimented developer in the concerned field (and Baire surely is my
first data structure library).

I don't know how the Caml-lib team feels it, but I first though
'initial' Baire would be the only one and I realized much later there
were a lot of wrong things in it.


        Diego Olivier

Re: [Ocaml-lib-devel] Re: [PATCH] updated enum: now concat uses t.fast

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

> > I'll try to review theses patch when I have some time.
> > I think it's good idea to remove the try..catch blocks when we have a
"fast"
> > count in concat and append, because they occur in each call to next .
But
> > for fold / iter , I'm not sure, mainly because a fast count can still be
> > O(N) and cost more than having one try...catch block setuped. Could you
do
> > some benchs using ExtList.enum instead of Enum.init ? The "fast" count
is
> > O(N) here in this case ( but is computed only once ). With big lists (
"when
> > we need speed" ) I'm pretty sure it will be better not to call count.
>
> I was operating under the assumption that "fast" would be set only for
> data structures that had their count readily available -- for
> instance, dynarray and init.

To get this behavior, it would mean that the user have to specify if it's
count() function is "fast" or not when constructing an Enum . Then it's
getting quite difficult for an new user to understand how to create Enums
and we're loosing the simplicity of them . "fast" should remain an internal
optimisation to distinguish the cases when we are calling "force" or not
when counting elements ( the minor speed improvement does not worth having a
more complex interface ).

Nicolas Cannasse