ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] DynArray

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

Nicolas Cannasse wrote:

> Hi !
> 
> I've have modified the DynArray module so it does not need anymore a null
> value. The only (small) tradeoff is that float dynarrays are boxed and that
> we need to copy element-by-element from and to float arrays instead of using
> Array primitives who must be faster.

Thanks!

I think this is a good start: it gets the interface right.
It is probably worth showing the Ocaml team, and asking what
they'd do to support unboxed arrays. Note that floats won't
be the only unboxed arrays, there's a good chance the team
is working to unbox all arrays of scalar types.

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

Re: [Ocaml-lib-devel] Future and status of extlib?

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

> First, is this forked library a derivative of CDK, so it includes all
> of the enhancements of CDK STDLIB derivative?

No its does not :
- first , extlib is sometimes overriding existing functions with same
specification (such as a tail recursive map) or different (raising different
exception). you can then use extlib as a replacement for stdlib (more like
an overriding of some functions + new functions) or as a set of new
functions (like the CDK).
- in the beginning we asked for useful functions that should be added and we
stated case-by-case which one should be or not. This is still "open" if you
have idea.
- after that, I have looked at the CDK and didn't find anything more worth
including (still need to look through the String2 module)

[...]
> Also, may I suggest that we release all of the stable modules and
> increment the patchlevel as soon as a new module is considered stable
> and complete. (And we only release (Put all Dev modules into a
> Stdlib.Dev submodule)

Only stable modules will be released, but this will not prevent us from
extending them later.
Dev modules should be only available through the CVS snapshot/version.

> Anyways, I have an modified version of the current STDLIB Set
> module. that supports Set.S.cardinal in constant time, I can improve
> it so that you can index into a set to get the *n*th element cheaply,
> and given an element can determine its index from the beginning. (This
> is useful if you want to use a Set to link to another datastructure.)

We actually need a Set in a defonctorized style , and with a signature that
looks more like Hashtbl ( with a default "empty" constructor that is using
compare).

> If so, how do I get access to CVS? I've never used sourceforge.

You can get anonymous access, read this :
http://sourceforge.net/cvs/?group_id=74666

Thanks for your interest in ExtLib.
Nicolas Cannasse

[Ocaml-lib-devel] Future and status of extlib?

[Scott A C. <sc...@cs...>]

Hello. I recently found a link to this project and I like the idea of
it. I hate reimplementing datastructures millions of times, so I'm
happy to see the existance of this project. I've got a couple of
questions and comments though..

First, is this forked library a derivative of CDK, so it includes all
of the enhancements of CDK STDLIB derivative?

Second, the few comments. 

IMHO, its better to have 3 very complete datastructure modules than
have 5 half-complete ones. As a user, I'd rather have 3 modules I can
use as-id, and implement two of my own than have to enhance 5 modules.

Also, may I suggest that we release all of the stable modules and
increment the patchlevel as soon as a new module is considered stable
and complete. (And we only release (Put all Dev modules into a
Stdlib.Dev submodule)



Anyways, I have an modified version of the current STDLIB Set
module. that supports Set.S.cardinal in constant time, I can improve
it so that you can index into a set to get the *n*th element cheaply,
and given an element can determine its index from the beginning. (This
is useful if you want to use a Set to link to another datastructure.)

Interested?

If so, how do I get access to CVS? I've never used sourceforge.

Scott

Re: [Ocaml-lib-devel] Further optimized UTF8.ml

[Yamagata Y. <yor...@mb...>]

I think this proposal was a bit rush, because the code size is
increased by 2K bytes.  In the attached file, both optimization
mentioned in the previous mail are removed but Obj.magic is used for
creation of uchar in "look".

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules

[Yamagata Y. <yor...@mb...>]

From: "Nicolas Cannasse" <war...@fr...>
Subject: Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules
Date: Wed, 25 Jun 2003 11:56:12 +0900

> if the code doesn't get bigger - since for some people
> space is more an issue than time - and if the source doesn't get ugly so it
> can still be maintained , modified , etc.

The code gets slightly bigger (160 bytes).  I am most concerned about
code duplication.  The code converter has several "magic" numbers and
formulas in it.  We had better to stuff them in one place, so that we
can easily review and modify them.

In my experience, (and judging from the woe stories caused by the
broken converters) writing a correct code converter is not easy.  To
err on the safe side is the better decision than reckless
optimization.

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] Dynarray (good one)

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

> - I don't think we're losing much (if anything) to using for loops instead
> of array blits.  We're moving whole words which are word aligned by
> definition, which is generally fast in general.  Memory bandwidth
> dominates.  I just used the array functions because I could.

If you look at the array.ml sources, you'll see that blit is actually doing
a for loop :-)

> - Are floats unboxed or boxed?  I thought boxed.  Note: in this case boxed

Sorry , I messed up when posting the mail : <<< floats ARE boxed >>>

[..]
> Meanwhile, with boxed floats, it would take 2*n + n*4/3 or 10/3 words per
> float, meaning the boxed version is only 25% more memory usage than the
> unboxed version.
[...]

Agree with you.

> - the problem of the array being mutated behind enum's back is a general
> problem with imperitive programming.  It's known as a "bug".  Note that my
> implementation may have had other problems, I didn't think about the
> enumerations that much.  I'd say leave the problem children out for now,
> and if there's demand for them later, we'll add them then.  Fight feeping
> creaturitist!

If I can't feel asleep one of theses nights, I will surely add them and
eventualy catch headache :)

> - Is there a reason you split off conservative_exponential_resizer from
> the normal exponential_resizer?  I didn't think the extra couple of

What do you mean here ?

> branchs were that bad, especially considering that normally you don't even
> reach them, and of the times you do you are hard limited to O(log N)
> iterations of either loop.  Especially considering you are calling resizer
> less often.  The default definately should be the conservative one.
> Correctness over small gains in speed.

I agree for conservative as default.

> - delete has a bug if you're not deleting the last element and not
> reallocating the array- the last element doesn't get nulled out.  It
> should be (about line 194):

Thanks, corrected

> - in to_array, can we replace the for loop with just:
>      Array.init d.len (fun i -> iget d.arr i)
> ?  This allocates a closure, which is it's only downside.

This one is only a inlining of the Array.init function.
A little better for speed, because no closure and better compilation since
same module.

> - of_array: do we want to call resizer to see what size to make the
> original array?  For example, if we're using step_resizer, and the array
> length is not a multiple of the step, the next time we do much of anything
> with the array we're reallocating the array.  Also, this means we don't
> have any space initially for inserting.  But this will make of_array more
> complicated, we can't just use idup.

Yes, but since resizes are most of the time amortized , resizing now or
later is not very important.

I also added "compact" that is shrinking the dynarray to it's minimum size.
I will commit the sources on the CVS now.

Nicolas Cannasse

Re: [Ocaml-lib-devel] Dynarray (good one)

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

A bunch of minor comments:

- I don't think we're losing much (if anything) to using for loops instead 
of array blits.  We're moving whole words which are word aligned by 
definition, which is generally fast in general.  Memory bandwidth 
dominates.  I just used the array functions because I could.

- Are floats unboxed or boxed?  I thought boxed.  Note: in this case boxed
floats are not the memory hog they might otherwise be, because of the
unused elements in the array.  The arrays are probably on average 5/8th to
3/4th full.  Assuming 3/4th full (assuming the array has been mostly
growing, and that it is on average halfway between just having been
expanded (50% full) and needing to be expanded again (100% full)), an
array of n unboxed floats would take up 2*n*4/3 or 8/3 words per float.  
Meanwhile, with boxed floats, it would take 2*n + n*4/3 or 10/3 words per
float, meaning the boxed version is only 25% more memory usage than the
unboxed version.

If the dynarray has mostly shrinking, it's on average halfway between 
having just been shrunk (25% full) and just about to be shrunk (12.5% 
full), meaning it's on average 3/16th full.  At this point unboxing floats 
takes up 2*n*16/3 or 32/2 words per float.  Boxing the floats, on the 
other hand, takes up 2*n + n*16/3 or 22/3 words per float, or 68.75% the 
memory unboxing floats would take.  So it can even save a signifigant 
amount of memory to not unbox floats.

- the problem of the array being mutated behind enum's back is a general 
problem with imperitive programming.  It's known as a "bug".  Note that my 
implementation may have had other problems, I didn't think about the 
enumerations that much.  I'd say leave the problem children out for now, 
and if there's demand for them later, we'll add them then.  Fight feeping 
creaturitist!

- Is there a reason you split off conservative_exponential_resizer from 
the normal exponential_resizer?  I didn't think the extra couple of 
branchs were that bad, especially considering that normally you don't even 
reach them, and of the times you do you are hard limited to O(log N) 
iterations of either loop.  Especially considering you are calling resizer 
less often.  The default definately should be the conservative one.  
Correctness over small gains in speed.

- delete has a bug if you're not deleting the last element and not 
reallocating the array- the last element doesn't get nulled out.  It 
should be (about line 194):

	end else begin
		if idx = d.len then
			(* erase for GC *)
			iset d.arr idx (Obj.magic 0)
		else
			for i = idx to d.len - 1 do
				iset d.arr i (iget d.arr (i+1));
			done;
			iset d.arr d.len (Obj.magic 0) (* <-- !!! *)
	end


- in to_array, can we replace the for loop with just:
     Array.init d.len (fun i -> iget d.arr i)
?  This allocates a closure, which is it's only downside.

- of_array: do we want to call resizer to see what size to make the 
original array?  For example, if we're using step_resizer, and the array 
length is not a multiple of the step, the next time we do much of anything 
with the array we're reallocating the array.  Also, this means we don't 
have any space initially for inserting.  But this will make of_array more 
complicated, we can't just use idup.

Brian


On Wed, 25 Jun 2003, Nicolas Cannasse wrote:

> Hi,
> 
> This new version of Dynarray is far better that the previous ones (including
> the one I posted) :
> - using a raw ocaml block with a polymorphic type
> - doing unchecked field access (since we're checking -by hand-)
> - no problems with floats (but they are unboxed)
> - testing for resizing only when removing an element or when not enough
> space for adding.
> - correct a lot of bugs (including a infinite loop in exp_resizer when
> having a length of 0 !)
> 
> Right now, I think the code is quite stable, although I can I have made some
> mistake here and there.
> Notice that I have removed a couple of *enum* functions since they need a
> little bit rethinking because the array can be muted after the enum is
> created : the ones currently defined are ok.
> 
> Comments/bugs report (of course) apprecied.
> 
> Nicolas Cannasse
> 

[Ocaml-lib-devel] Further optimized UTF8.ml

[Yamagata Y. <yor...@mb...>]

I do more optimization of UTF8.ml

  * Reordering tests in add_uchar (as John Max Skaller sugested.),
    which makes the encoder 3-5% faster.

  * iter is optimized by unsafe operations (about 30% improvement)

--
Yamagata Yoriyuki


  

[Ocaml-lib-devel] Dynarray (good one)

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

Hi,

This new version of Dynarray is far better that the previous ones (including
the one I posted) :
- using a raw ocaml block with a polymorphic type
- doing unchecked field access (since we're checking -by hand-)
- no problems with floats (but they are unboxed)
- testing for resizing only when removing an element or when not enough
space for adding.
- correct a lot of bugs (including a infinite loop in exp_resizer when
having a length of 0 !)

Right now, I think the code is quite stable, although I can I have made some
mistake here and there.
Notice that I have removed a couple of *enum* functions since they need a
little bit rethinking because the array can be muted after the enum is
created : the ones currently defined are ok.

Comments/bugs report (of course) apprecied.

Nicolas Cannasse

Re: [Ocaml-lib-devel] DynArray

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

> If I understand correctly, the problem is that using "Obj.magic 0" as
> a null causes a segfault.  It is because de-reference occurs when
> inserting floats into float arrays.

Actually not.
The tag of the array saying it can be Double_array or 0 (normal array)
depends on the init value you create it with : if the value have the
Double_val tag then we're creating a (unboxed) float array.
In fact, you can create a boxed float array just by calling :

let fa = (Obj.magic (Array.make n 0) : float array)

that will work correctly, since insertion will test for the Double_array_tag
of the array, and not test for the inserted element tag.

But hold your breath , I'm currently working on a far better version that
doesn't need any more Obj.magic and that is working with an abstract type
which is in fact a raw ocaml block with tag 0 (exactly the same as an array,
but never makes test for Double_array_tag nor bounds checking : better since
we're already testing them in the DynArray library).

Nicolas Cannasse

Re: [Ocaml-lib-devel] DynArray

[Yamagata Y. <yor...@mb...>]

If I understand correctly, the problem is that using "Obj.magic 0" as
a null causes a segfault.  It is because de-reference occurs when
inserting floats into float arrays.

If it is true, then Michal Moskal's approach seems most elegant to
me.  (using "ref 0.0" as a null value.)  If relying the fact that
references and boxed floats are same structures is not acceptable, you
can test whether the given array is a float array by looking its block
tag.  The test is needed only in creation and resizing.  (Though you
may think theses options already.)

--
Yamagata Yoriyuki

[Ocaml-lib-devel] DynArray

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

Hi !

I've have modified the DynArray module so it does not need anymore a null
value. The only (small) tradeoff is that float dynarrays are boxed and that
we need to copy element-by-element from and to float arrays instead of using
Array primitives who must be faster.
I have some idea for keeping the float arrays unboxed but I might lead to a
more complex code and will surely trade space for speed since we will need
to do some tests in most of the calls. Here's the source code, any
comments/tests grealty apprecied before commit.

I also fixed some bugs on the way , and I'm currently wondering why the
resizer function is called every time we add/insert an element , even is
there is space available ? this should be corrected.

Nicolas Cannasse

Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules

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

> > I do some benchmarks.  While the test repeating "buf.add_uchar 'a'
> > buf" and "buf.clear buf" shows 25% speed up, the more realistic test
> > that repeatedly puts 1K uchars into a buffer shows only 3% speed up.
> > Not a big deal, really.
>
> Yes it is. It is a big deal. Let me ask you something:
>
> would you give up 3% interest on an investment?
> would you give 3% of a year extra to your employer
> instead of holidays? That's about 11 days of holidays,
> which is two whole weeks .. around here that's the whole
> of your Xmas holdiday .. and over half your total holidays.

The thing here is that if we're sure to get a 3% improvement, then it's
perhaps worth it ( if the code doesn't get bigger - since for some people
space is more an issue than time - and if the source doesn't get ugly so it
can still be maintained , modified , etc. ).
But since hardware are different, memory issues and not-so-good process
timing, you can be pretty sure that this 3% is not relevent, and then a +3%
on Yamagata-san computer can be a -10% on my windows box for example :-)
Always be careful with micro benchmarks, watch the generated assembly code
(using ocamlopt -S) to be sure that this actually an optimisation !

Nicolas Cannasse

Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules

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

Yamagata Yoriyuki wrote:


>>Well, if I go i18n, I want the decoder function
>>as fast as possible (the encoder is less critical).
>>
> 
> The part we talked about is the encoder, not the decoder.  (the
> decoder is look function.)


I know.


> I do some benchmarks.  While the test repeating "buf.add_uchar 'a'
> buf" and "buf.clear buf" shows 25% speed up, the more realistic test
> that repeatedly puts 1K uchars into a buffer shows only 3% speed up.
> Not a big deal, really.

Yes it is. It is a big deal. Let me ask you something:

would you give up 3% interest on an investment?
would you give 3% of a year extra to your employer
instead of holidays? That's about 11 days of holidays,
which is two whole weeks .. around here that's the whole
of your Xmas holdiday .. and over half your total holidays.

You might think the comparison is unfair.
But software systems compete on margins, like
anything else. 3% off an overhead is a good improvement.
Get it fast enough and the case for recoding
in C -- or even assembler -- will diminish.

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

Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules

[Yamagata Y. <yor...@mb...>]

From: John Max Skaller <sk...@oz...>
Subject: Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules
Date: Tue, 24 Jun 2003 03:30:06 +1000

> Well, if I go i18n, I want the decoder function
> as fast as possible (the encoder is less critical).

The part we talked about is the encoder, not the decoder.  (the
decoder is look function.)

I do some benchmarks.  While the test repeating "buf.add_uchar 'a'
buf" and "buf.clear buf" shows 25% speed up, the more realistic test
that repeatedly puts 1K uchars into a buffer shows only 3% speed up.
Not a big deal, really.

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules

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

Yamagata Yoriyuki wrote:


> k could be negative.  A better way is
> 
>   if k >= 0 then
>      if k <= 0x7f then ... else
>      if k <= 0x7ff then ... else
>      ...
>      if k <= 0x3ffffff then ... else
>      (*)
>   else
>      (*)
> 
> but then the code (*) is duplicated.  I don't think an extra integer
> comparison is a big deal.


I do, because, I may UTF-8 every input file to my compiler.

Since lexical analysis is the slowest part of compilation,

and this routine is handling every character individually,
blinding speed is important. Adding 50% more comparisons
to handle an ASCII character may slow the lexer, and thereby
the whole compilation process, by a significant amount.
I'm already thinking to replace Ocamllex, since the
space compaction on the lookup tables costs performance :-)
Also tempted to mmap the input file, to eliminate the
check for end of buffer needed on each char.

After all, the core of a scanner is ultra fast:

	while(state = matrix[state][*p++]);

which should outperform memory easily.
Well, if I go i18n, I want the decoder function
as fast as possible (the encoder is less critical).

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

Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules

[Yamagata Y. <yor...@mb...>]

Argh, I found a bug in uTF8.ml.  Here is a fix.

Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules

[Yamagata Y. <yor...@mb...>]

From: "Nicolas Cannasse" <war...@fr...>
Subject: Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules
Date: Mon, 23 Jun 2003 17:55:16 +0900

> I'm pretty sure it is doing it.
> Since masq is non-mutable, this is an easy optimisation for the compiler.
> BTW, you can check the native output code by running ocamlopt with -S

It does.

> The other thing to do here is reorder the tests:
> test k>=0 && k<=07f first, then k<=07ff ..., reason being
> that the first case is 99.99% of cases. The second
> is 99.99% of the rest of cases.

k could be negative.  A better way is

  if k >= 0 then
     if k <= 0x7f then ... else
     if k <= 0x7ff then ... else
     ...
     if k <= 0x3ffffff then ... else
     (*)
  else
     (*)

but then the code (*) is duplicated.  I don't think an extra integer
comparison is a big deal.

More optimization also could be possible by the unsafe operations.
For example, iter can use unsafe_next. (which does not check whether
i is valid.)

let rec iter_aux proc s i =
  if i >= String.length s then () else
  let u = look s i in
  proc u;
  iter_aux proc s (next s i)

But, it makes the code duplicated (unsafe_next and next.  If we
implement next using unsafe_next, then we add one extra function call
for the safe operation1, which is IMO not desirable.) and makes the
code more prone to error.  (In this case, we implicitly assume
inter_aux never be called with i < 0.)

My opinion is that uTF8.ml is already optimized well, unless we have a
good benchmark.

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules

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

> > let add_uchar buf u =
> >   let masq = 0b111111 in
> >   let k = int_of_uchar u in
> >   if k < 0 || k >= 0x4000000 then begin
> >     Buffer.add_char buf (Char.chr (0xfc + (k lsr 30)));
> >     Buffer.add_char buf (Char.unsafe_chr (0x80 lor ((k lsr 24) land
masq)));
>
> You might try replacing 'masq' with the actual literal value,
> though the compiler should be able to determine its a constant,
> it may not.

I'm pretty sure it is doing it.
Since masq is non-mutable, this is an easy optimisation for the compiler.
BTW, you can check the native output code by running ocamlopt with -S

> The other thing to do here is reorder the tests:
> test k>=0 && k<=07f first, then k<=07ff ..., reason being
> that the first case is 99.99% of cases. The second
> is 99.99% of the rest of cases.

This one the compiler can't :-)

Nicolas Cannasse

Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules

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

> Is there other things to do for the inclusion?

Once everybody will be happy with it, I will commit it to ExtLib.

Nicolas Cannasse

Re: [Ocaml-lib-devel] CVS issue

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

Nicolas Cannasse wrote:
> 
> > sh: /cvsroot/ocaml-lib/CVSROOT/commit.log: Permission denied
> >
> > Committed some changes to doco in enum.mli.
> >
> > Looks like a bug in sourceforge CVS setup,
> > don't see how this is possible though... its heavily
> > used by multiple developers.
> 
> In the early days, I modified the configuration to have a commit log being
> done in some file , but the process doesn't have access to the commit.log
> file . I asked SF team to modify it, they answered later it was done, but
> actually looks like they messed up. Maybe later I will take care of it ,
> right know please just ignore this message.

If people want, I can set up a Subversion repos for ExtLib.  I've already
got one for my Orca open source project <http://www.orcaware.com/orca/>
See

http://svn.orcaware.com/

for the Orca SVN repository.  I've also got Mailman, so we could set up a
commit mailing list.

For those who aren't familiar with Subversion, it's designed as the
successor to CVS.  See

http://subversion.tigris.org/

for a list of features that make it better then CVS.

Best,
Blair

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

Re: [Ocaml-lib-devel] second proposal of UChar, UTF8 modules

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

Yamagata Yoriyuki wrote:

> let add_uchar buf u =
>   let masq = 0b111111 in
>   let k = int_of_uchar u in
>   if k < 0 || k >= 0x4000000 then begin
>     Buffer.add_char buf (Char.chr (0xfc + (k lsr 30)));
>     Buffer.add_char buf (Char.unsafe_chr (0x80 lor ((k lsr 24) land masq))); 

You might try replacing 'masq' with the actual literal value,
though the compiler should be able to determine its a constant,
it may not.

The other thing to do here is reorder the tests:
test k>=0 && k<=07f first, then k<=07ff ..., reason being
that the first case is 99.99% of cases. The second
is 99.99% of the rest of cases.

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

Re: [Ocaml-lib-devel] Exception handling tools

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

> val catch_all : ('a -> 'b) -> 'a -> 'b option

I REALLY don't like the idea of "catching+ignoring all exceptions". That
would encourage programmers to write incorrect code.

> val catch: exn list -> ('a -> 'b) -> 'a -> 'b option
> val catch_not: exn list -> ('a -> 'b) -> 'a -> 'b option
> val tr_exn: (exn * exn) list -> ('a -> 'b) -> 'a -> 'b

I'm not really sure about theses.
Actually it's true we're sometimes doing something like

try
      List.find my_pred my_list
with
    Not_found -> raise My_exception

But I'm not sure that writing :

tr_exn [(Not_found,My_exception)] (List.find my_pred) my_list

is more readable.
And more than that, most of the time, you want to raise an exception with
some parameter. Then theses functions are getting a litlle less usable ( +
performances of list allocation and search ).

Nicolas Cannasse

Re: [Ocaml-lib-devel] CVS issue

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

> sh: /cvsroot/ocaml-lib/CVSROOT/commit.log: Permission denied
>
> Committed some changes to doco in enum.mli.
>
> Looks like a bug in sourceforge CVS setup,
> don't see how this is possible though... its heavily
> used by multiple developers.

In the early days, I modified the configuration to have a commit log being
done in some file , but the process doesn't have access to the commit.log
file . I asked SF team to modify it, they answered later it was done, but
actually looks like they messed up. Maybe later I will take care of it ,
right know please just ignore this message.

Nicolas Cannasse

Re: [Ocaml-lib-devel] Enum documentation and bug fix

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

> > On Fri, 20 Jun 2003, Nicolas Cannasse wrote:
>
> > This is one place where has_next would be usefull.

we have it : Enum.empty : 'a t -> bool

> But it is a significant change in semantics because
>
> it requires one element lookahead. Some data structures
> cannot support that without side effects, for example
> reading the next line of a file.

Enum is handling that for you , but it have a cost since you're needing to
do some functional trick.
The way iter2 is currently implemented is better thab using empty every time
(the element is only pushed back in the enum once).

Nicolas Cannasse