ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] Array interface

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

[...]
> Nah, just box the floats.
> Should be easy. Make the underlying array
> type int. Use 0 as the null value.
> Use casts to convert incoming and outgoing
> values. Easy. Floats stay boxed though.
> I don't care.

I agree with that one, it would be interesting to improve DynArray this way.
you need also to copy elements one_by_one instead of doing Array.sub in
DynArray.to_array.

Nicolas Cannasse

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

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

> > I added the complete documention to Enum. (comments are welcome )
> > While reading the documentation specification, I found a bug.
> > Actually the iter2 , fold2 and others were not correct because of the
> > following
> >
> > f (t.next()) (u.next())
> >
> > if t.next() was called and then u.next() was raising No_more_elements ,
we
> > were loosing an element of t.
>
> I think that the iter2 function only makes sense when used on two
> enums of the same count.  I suggest simply documenting that the
> behavior is undefined when used on two enums of differing counts.

Not exactly.
I can think of some samples which are worth the bugfix.
You can do iter2 on two enums, and then want to do "something" with the
remaining elements.

Nicolas Cannasse

Re: [Ocaml-lib-devel] Array interface

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

Brian Hurt wrote:


>>C++ vector does this correctly.
>>
> 
> At the cost of emitting a whole new wad og object code for every single 
> type you put into a vector.  Vector<int> requires the compiler to produce 
> a whole vector class to deal with ints, seperate from Vector<short>, 
> Vector<char>, Vector<void *>, etc.  


Your comparison is unfair and untrue.

If you make the equivalent vector to ocaml,
you'd make a vector of pointers.

It is in fact easy and common practice to specialise
vector on pointers to use the code for a
vector<void*> plus casts wrapped in the template.
Most compilers will optimise this to the calls
to the void* specialisation if the wrappers
are inline.

So no code bloat. On the contrary, C++ has a built-in
mechanism for handling specialisations and Ocaml does
not, so in this area it is way ahead of Ocaml:
put another way: if you have unboxed types and pointers,
you can always use boxed types. The reverse is not true.

Ocaml is in fact based on a faulty type system,
which fails to recognize that copying values cannot
be handled polymorphically: it cheats by using boxing.
There are a few areas where this fault is evident,
for example recursive types: the usual definition
is in fact quite wrong: the unfold of a recursive
type is a distinct type. Its only isomorphic
to the original if the types are replaced by pointers.

The principal problem in C++ here is the lack of
a garbage collector. The code bloat from the specialisations
is the price for high performance: ocaml is doing that too
with unboxed arrays of floats etc .. but it will never
compete with C++ in this area: the ocaml team has
to 'hack' the underlying implementation to gain
performance. The C++ end user can do it easily
and more reliably. In fact.. its the default :-)


> In this case, you're going to be using a 'a option Dynarray.t one way or 
> another.  The question is wether you can ever get rid of the option part.


Nah, just box the floats.
Should be easy. Make the underlying array
type int. Use 0 as the null value.
Use casts to convert incoming and outgoing
values. Easy. Floats stay boxed though.
I don't care.

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

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

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

In article <000701c336cf$1709bc30$2713f9ca@WARP>, Nicolas Cannasse wrote:
> I added the complete documention to Enum. (comments are welcome )
> While reading the documentation specification, I found a bug.
> Actually the iter2 , fold2 and others were not correct because of the
> following
> 
> f (t.next()) (u.next())
> 
> if t.next() was called and then u.next() was raising No_more_elements , we
> were loosing an element of t.

I think that the iter2 function only makes sense when used on two
enums of the same count.  I suggest simply documenting that the
behavior is undefined when used on two enums of differing counts.

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

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

I added the complete documention to Enum. (comments are welcome )
While reading the documentation specification, I found a bug.
Actually the iter2 , fold2 and others were not correct because of the
following

f (t.next()) (u.next())

if t.next() was called and then u.next() was raising No_more_elements , we
were loosing an element of t.
I modified the implementation of theses so now the element is saved and
pushed back (using the new "push" function) if needed.
But as for map2 (and map2i) this would involve setting up a try .. catch
block for every call to next , which has already been tagged as
not-so-efficient , I have then temporay removed theses two.

Nicolas Cannasse

Re: [Ocaml-lib-devel] I lied- had time to work on ExtList after all

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

> > What I thought was going to be a long meeting turned out to be a short
> > meeting, so I took a spin through ExtList (attached).  If there aren't
any
> > comments, I'll check it in tomorrow.
> >
> > Brian
> >
> >
> > module List = struct
> >
>
>
> How do I use this module without clobbering
> the one in the standard distribution?

open ExtLib

will do the job.
This as already been discussed on this list, and should be included in the
ExtLib documentation introduction : "how to use extlib".

> Do I just add a path component to the compiler command line?
> So then, I can't revert to the List in the distribution
> within a single file?

Reverting is not a good thing , since we're adding functions and even
modifying some behaviors.
If you have existing code, either you add "open ExtList" to override the
ocaml std one, or you can do "open ExtLib" to be able to access new
functions via the ExtList module.

Nicolas Cannasse

Re: [Ocaml-lib-devel] I lied- had time to work on ExtList after all

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

On Thu, 19 Jun 2003, John Max Skaller wrote:

> Brian Hurt wrote:
> 
> > What I thought was going to be a long meeting turned out to be a short 
> > meeting, so I took a spin through ExtList (attached).  If there aren't any 
> > comments, I'll check it in tomorrow.
> > 
> > Brian
> > 
> > 
> > module List = struct
> >
> 
> 
> How do I use this module without clobbering
> the one in the standard distribution?

This is actually a good question, and I'm not sure I have a good answer.  
Nicolas- should this maybe be:

module ExtList = struct

??  And then rename it in extLib?

Most of my thinking about this module has been about using it in place of 
the standard libraries- but I could see people wanting the enum parts 
without wanting to run the risk of bugs in the rest of the routines.

Brian

Re: [Ocaml-lib-devel] A proposal for Unicode character and UTF-8 modules.

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

> > I think that one of the thing that could be done is to merge the two
modules
> > into one
>
> I made UChar and UTF-8 two different modules because,
>
>   * Char and String are different modules, and I want to make unicode
>   modules similar to the string API of stdlib as far as possible, and
>
>   * Users, or eventually we, may provide other Unicode string (UTF-16,
>     UCS-4, BOCU, or whatever).  Making UTF-8 an independent module
>     would make changing Unicode string implementation easier.
>
> If nested modules are acceptable, we can pack them into one module, of
> course.

No it's ok this way :-)

> > work a little on function/type naming and better exception
> > handling.
>
> Is it better to define its own exception than to use invalid_arg?
> Currently, UTF-8 module don't do bound checking itself for the
> performance reason.  Is it better to do bound checking in UTF-8, and
> raise its own exception other than Invalid_arg?

Depends.
ExtLib exception policy is the following :
- if exception should be catched , then use a module-specific exception
- if exception is a programmer failure, then you can use invalid_arg or
failwith
Theses statement come from the fact that invalid_arg and failwith are
type-unsafe since you need to catch them with the good string in order to
have a correct catching behavior. Using module-specific exceptions, even
with a string parameter, reduce the number of bad-catchs.

In the case of parsing (xml , unicode, etc.) the data often comes from an
external source, and the programmer will most of the time want to handle
parsing failures , theses should then not be considered as "exceptions worth
catching" and declared as module-specific exceptions.

Nicolas Cannasse

Re: [Ocaml-lib-devel] A proposal for Unicode character and UTF-8 modules.

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

From: John Max Skaller <sk...@oz...>
Subject: Re: [Ocaml-lib-devel] A proposal for Unicode character and UTF-8 modules.
Date: Thu, 19 Jun 2003 22:51:32 +1000

> > let look s i =
> >   let n' =
> >     let n = Char.code s.[i] in
> >     if n < 0x80 then n else
> >     if 0xc2 <= n && n <= 0xdf then
> >       look_code s (i + 1) 1 (n - 0xc0)
> >     else if 0xe0 <= n && n <= 0xef then
> >       look_code s (i + 1) 2 (n - 0xe0)
> >     else if 0xf0 <= n && n <= 0xf7 then
> >       look_code s (i + 1) 3 (n - 0xf0)
> >     else if 0xf8 <= n && n <= 0xfb then
> >       look_code s (i + 1) 4 (n - 0xf8)
> >     else if 0xfc <= n && n <= 0xfd then
> >       look_code s (i + 1) 5 (n - 0xfc)
> >     else invalid_arg "UTF8"
> >   in
> >   uchar_of_int n'
> 
> 
> This is inefficient. you want:
> 
> 	if n <= 0x7F then n else
> 	if n <= 0xc1 then invalid_arg "UTF8" else
> 	if n <= 0xdf then ...

It was intentional, mostly for documentation.  But you may be right.
Also it would be better to unroll look_code for performance.
Performance of other functions can be improved, too, I think.  (I
gradually recall the thought behind the code, which is about one year
old.)

From: John Max Skaller <sk...@oz...>
Subject: Re: [Ocaml-lib-devel] A proposal for Unicode character and UTF-8 modules.
Date: Thu, 19 Jun 2003 23:07:42 +1000

> 	ustring -- string of UCS-4 (32 bit values)

I have UCS-4 implementation by ocaml int array, too.  I can contribute
it.  As for int32 vs int, is it acceptable to use in Extlib?  UTF-16
needs 16-bit int array, and implementation of UCS-4 by 32-bit int
array would have an advantage for C FFI.

From: John Max Skaller <sk...@oz...>
Subject: Re: [Ocaml-lib-devel] A proposal for Unicode character and UTF-8 modules.
Date: Thu, 19 Jun 2003 23:07:42 +1000

> In addition, I need to be able to convert literals.
> These things also have various C like escapes in them,
> including
> 
> 	\uXXXX and \UXXXXXXXX
> 
> escapes. My constant folder must also be able to
> concatenate strings, etc.

Is this style of escaping used in the ISO standard?  I think the Unicode
book (Ver 3.2) uses \uXXXX and \vXXXXXXXX.  If yours is the ISO standard,
then I would use yours.  Concatenation is easy, because UTF-8 type is
currently just ocaml string.  But I could add more API.  Maybe all
functions appeared in String except the ones depending on locale
(casing, I mean)?  

> I don't actually need
> the code to be fast, but I do need a way to enforce
> the typing properly -- I don't want to mix up
> the string and bytestring.

Ideally, I would agree you.  But in current ocaml, a string literal is
a bytestring, and pattern matching don't work for an abstract type.  So,
I think it is better that we retain the equality UTF8.t = string in
this stage.  Anyway, I think the equivalence to ASCII string in the
case of ASCII characters is the only advantage of UTF-8.  If we can
satisfy the abstract unicode string, then it would be better to use
UTF-16 or UCS-4.

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] A proposal for Unicode character and UTF-8 modules.

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

Thank you for the comment.

From: "Nicolas Cannasse" <war...@fr...>
Subject: Re: [Ocaml-lib-devel] A proposal for Unicode character and UTF-8 modules.
Date: Thu, 19 Jun 2003 14:14:31 +0900

> I think that one of the thing that could be done is to merge the two modules
> into one

I made UChar and UTF-8 two different modules because,

  * Char and String are different modules, and I want to make unicode
  modules similar to the string API of stdlib as far as possible, and

  * Users, or eventually we, may provide other Unicode string (UTF-16,
    UCS-4, BOCU, or whatever).  Making UTF-8 an independent module
    would make changing Unicode string implementation easier.

If nested modules are acceptable, we can pack them into one module, of
course.

> work a little on function/type naming and better exception
> handling.

Is it better to define its own exception than to use invalid_arg?
Currently, UTF-8 module don't do bound checking itself for the
performance reason.  Is it better to do bound checking in UTF-8, and
raise its own exception other than Invalid_arg?

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] I lied- had time to work on ExtList after all

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

On Thu, 19 Jun 2003, Nicolas Cannasse wrote:

> > What I thought was going to be a long meeting turned out to be a short
> > meeting, so I took a spin through ExtList (attached).  If there aren't any
> > comments, I'll check it in tomorrow.
> 
> I think there is still a lot of functions who will need the "dummy_node"
> trick, for example map , remove and some more. That simplify a lot the
> source code because we don't have to match every time with the empty list.

I'll take another spin through it this weekend.  If we're going to use the 
trick at all, we might as well use the trick were convient.

Brian

Re: [Ocaml-lib-devel] Array interface

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

On Thu, 19 Jun 2003, John Max Skaller wrote:

> Brian Hurt wrote:
> 
> > On Tue, 17 Jun 2003, John Skaller wrote:
> 
> >>Can't you initialise the empty slots with Obj.magic(0)?
> >>
> > No.  What if it's an array of floats, which is unboxed?
> 
> 
> Ah.
> 
> 
> > If you don't have a convient default, use a 'a option Dynarray.t.  
> 
> 
> No way. That's a hack to support a faulty implementation.
> I want a 'a Dynarray.t, the *filled* slots always have that type.
> I don't see why I should change the type to suit an implementation
> that can't handle the idea of a variable length array properly.

As I can't use Obj.magic() if it's an array of floats, the only other
option I have is to make *everything* a 'a option Dynarray.t implicitly-
make the internal array a 'a option array instead of just a 'a array.  
Which means if it's a dynarray of ints, the ints are not unboxed.  
Futhermore, if I understand things correctly, the ints aren't unboxed in
the option variable either- meaning that I've now added two dereferences
and two extra words for every integer in the array- when I can instead
just use an integer array in the current implementation.

> 
> C++ vector does this correctly.

At the cost of emitting a whole new wad og object code for every single 
type you put into a vector.  Vector<int> requires the compiler to produce 
a whole vector class to deal with ints, seperate from Vector<short>, 
Vector<char>, Vector<void *>, etc.  

> 
> > Note: in the current API there is no way to get access to an element with 
> > a null value.  So you don't ever have to worry about distinguishing null 
> > values from sensible values.  So it's still safe if the null value would 
> > otherwise have meaning.
> 
> 
> I have examples where I CANNOT construct a dummy value.
> The fact that the value is not accessible with
> an array access cannot remove a requirement
> an object may have to connect to other objects.

In this case, you're going to be using a 'a option Dynarray.t one way or 
another.  The question is wether you can ever get rid of the option part.

> It could be there is NO good solution in Ocaml.
> In that case, use a C solution. I want this
> data structure to work exactly right, and I need
> it precisely *because* I can't define it myself.

Feel free to submit code.  

Brian

Re: [Ocaml-lib-devel] A proposal for Unicode character and UTF-8 modules.

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

Remi Vanicat wrote:

> "Nicolas Cannasse" <war...@fr...> writes:
> 
> 
>>>Here are proposals for Unicode character and UTF-8 modules.  They were
>>>part of my camomile library, and passed the random tests.

> by the way, lablgtk2 and pcre-ocaml already have some UTF-8 code
> handling, so may be one can begin by looking there.
 
So too does Felix. The routines look good.


I'm going to check with my compiler to see
if I can do what I want. I need several concepts:

	bytestring -- string of bytes

	string -- string of text, ISO-10646/Unicode
		using UTF-8 encoding

	ustring -- string of UCS-4 (32 bit values)

In addition, I need to be able to convert literals.
These things also have various C like escapes in them,
including

	\uXXXX and \UXXXXXXXX

escapes. My constant folder must also be able to
concatenate strings, etc. I don't actually need
the code to be fast, but I do need a way to enforce
the typing properly -- I don't want to mix up
the string and bytestring.

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

Re: [Ocaml-lib-devel] I lied- had time to work on ExtList after all

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

Brian Hurt wrote:

> What I thought was going to be a long meeting turned out to be a short 
> meeting, so I took a spin through ExtList (attached).  If there aren't any 
> comments, I'll check it in tomorrow.
> 
> Brian
> 
> 
> module List = struct
>


How do I use this module without clobbering
the one in the standard distribution?

Do I just add a path component to the compiler command line?
So then, I can't revert to the List in the distribution
within a single file?

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

Re: [Ocaml-lib-devel] A proposal for Unicode character and UTF-8 modules.

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

Yamagata Yoriyuki wrote:

> Here are proposals for Unicode character and UTF-8 modules.  They were
> part of my camomile library, and passed the random tests.


Good start here.

> let look s i =
>   let n' =
>     let n = Char.code s.[i] in
>     if n < 0x80 then n else
>     if 0xc2 <= n && n <= 0xdf then
>       look_code s (i + 1) 1 (n - 0xc0)
>     else if 0xe0 <= n && n <= 0xef then
>       look_code s (i + 1) 2 (n - 0xe0)
>     else if 0xf0 <= n && n <= 0xf7 then
>       look_code s (i + 1) 3 (n - 0xf0)
>     else if 0xf8 <= n && n <= 0xfb then
>       look_code s (i + 1) 4 (n - 0xf8)
>     else if 0xfc <= n && n <= 0xfd then
>       look_code s (i + 1) 5 (n - 0xfc)
>     else invalid_arg "UTF8"
>   in
>   uchar_of_int n'


This is inefficient. you want:

	if n <= 0x7F then n else
	if n <= 0xc1 then invalid_arg "UTF8" else
	if n <= 0xdf then ...

i.e. you can assume the previous range test
failed, so just check for endpoints of ranges
in ascending order.
-- 
John Max Skaller, mailto:sk...@oz...
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850

Re: [Ocaml-lib-devel] Array interface

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

Brian Hurt wrote:

> On Tue, 17 Jun 2003, John Skaller wrote:

>>Can't you initialise the empty slots with Obj.magic(0)?
>>
> No.  What if it's an array of floats, which is unboxed?


Ah.


> If you don't have a convient default, use a 'a option Dynarray.t.  


No way. That's a hack to support a faulty implementation.
I want a 'a Dynarray.t, the *filled* slots always have that type.
I don't see why I should change the type to suit an implementation
that can't handle the idea of a variable length array properly.

C++ vector does this correctly.

> Note: in the current API there is no way to get access to an element with 
> a null value.  So you don't ever have to worry about distinguishing null 
> values from sensible values.  So it's still safe if the null value would 
> otherwise have meaning.


I have examples where I CANNOT construct a dummy value.
The fact that the value is not accessible with
an array access cannot remove a requirement
an object may have to connect to other objects.

In particular, consider a type in which a representation
of an open file handle is stored. Now you force
me to create a dummy file in the file system just
to create an array.

It could be there is NO good solution in Ocaml.
In that case, use a C solution. I want this
data structure to work exactly right, and I need
it precisely *because* I can't define it myself.

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

Re: [Ocaml-lib-devel] A proposal for Unicode character and UTF-8 modules.

[Remi V. <van...@la...>]

"Nicolas Cannasse" <war...@fr...> writes:

>> Here are proposals for Unicode character and UTF-8 modules.  They were
>> part of my camomile library, and passed the random tests.
>>
>> I do not know the coding convention of Extlib.  So, I am virtually
>> certain that there are many point that must be fixed.
>
> Thanks !
> I think that one of the thing that could be done is to merge the two modules
> into one , and work a little on function/type naming and better exception
> handling. Once done , it should be ready to be added in ExtLib.
> Since I'm not aware of unicode/utf-8 encoding, I can't comment on the
> interface design or on the implementation. People who already have used such
> features (in others langages as OCaml) are welcome to comment this
> proposal.

by the way, lablgtk2 and pcre-ocaml already have some UTF-8 code
handling, so may be one can begin by looking there.
-- 
Rémi Vanicat
va...@la...
http://dept-info.labri.u-bordeaux.fr/~vanicat

[Ocaml-lib-devel] Way to 1.0

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

Modules that will be included in 1.0 :

(extensions to ocaml stdlib)
- ExtArray : missing implementation and incomplete documentation
- ExtHashtbl : missing implementation and incomplete documentation
- ExtList : missing documentation
- ExtString : incomplete documentation
- Std : missing documentation

(new modules)
- DynArray :  should be OK
- Enum : missing documentation
- Global : should be OK
- Option : should be OK
- Psqueue : still have bug ? should be OK
- RefList : missing little documentation

(if ready before release)
- Unicode by Yamagata Yoriyuki
- BinTree (mutable Set) by Diego Olivier Fernandez Pons

The 1.0 will be freely shipped for all ocaml people in the world :-)
Will be released as a source TGZ or ZIP.
For compilation, I think it's a good idea to include ocamake.ml and then
have a script/Makefile that first compile ocamake and then run it.
Windows precompiled binaries will be also available.

Time to relase : few weeks.
If people are interested in code/documentation review, please browse the CVS
at Sourceforge ( http://sourceforge.net/projects/ocaml-lib ) and report any
bug/problem on this mailling list.

Nicolas Cannasse

Re: [Ocaml-lib-devel] I lied- had time to work on ExtList after all

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

> What I thought was going to be a long meeting turned out to be a short
> meeting, so I took a spin through ExtList (attached).  If there aren't any
> comments, I'll check it in tomorrow.

I think there is still a lot of functions who will need the "dummy_node"
trick, for example map , remove and some more. That simplify a lot the
source code because we don't have to match every time with the empty list.

Nicolas Cannasse

Re: [Ocaml-lib-devel] A proposal for Unicode character and UTF-8 modules.

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

> Here are proposals for Unicode character and UTF-8 modules.  They were
> part of my camomile library, and passed the random tests.
>
> I do not know the coding convention of Extlib.  So, I am virtually
> certain that there are many point that must be fixed.

Thanks !
I think that one of the thing that could be done is to merge the two modules
into one , and work a little on function/type naming and better exception
handling. Once done , it should be ready to be added in ExtLib.
Since I'm not aware of unicode/utf-8 encoding, I can't comment on the
interface design or on the implementation. People who already have used such
features (in others langages as OCaml) are welcome to comment this proposal.

Nicolas Cannasse

[Ocaml-lib-devel] I lied- had time to work on ExtList after all

[Brian H. <bh...@sp...>]

What I thought was going to be a long meeting turned out to be a short 
meeting, so I took a spin through ExtList (attached).  If there aren't any 
comments, I'll check it in tomorrow.

Brian

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

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

On Tue, 17 Jun 2003, Nicolas Cannasse wrote:

> List.map is not the same as List.fold !
> - with fold, you can "skip" elements in a list, doing then a filter_map
> - you can access the accumulator , and this is useful in many cases (no
> duplicates for example)

Point.

> 
> I suggest having something like :
> 
> let fold f l =
>     let x = [ Obj.magic () ] in
>     let rec loop dst = function
>         | [] -> ()
>         | h :: t ->
>             let r = [ f h (List.tl x) ] in
>             Obj.set_field (Obj.repr dst) 1 (Obj.repr r);
>             loop r t
>     in
>     loop x;
>     List.tl x

Maybe combine this with filter_map-like capabilities?  Something like:

let foo f l =
    let x = [ Obj.magic () ] in
    let rec loop dst = function
        | [] -> ()
        | h :: t ->
           match f h (List.tl x) with
               None -> loop dst t
               | Some x -> 
                   let r = [ x ] in 
                   Obj.set_field (Obj.repr dst) 1 (Obj.repr r);
                   loop r t
    in
    loop x lst;
    List.tl x

Brian

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

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

On Tue, 17 Jun 2003, Nicolas Cannasse wrote:

> > Just had an idea for ExtList.fold_right.  Ok, there are basically two
> > different possible implementations: the non-tail-recursive version:
> [...]
> 
> I might have solve the problem with a better implementation :

This is a better implementation.  The extra overhead is only a single 
increment per loop- maybe one extra clock cycle, possibly not even that.

Brian

[Ocaml-lib-devel] A proposal for Unicode character and UTF-8 modules.

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

Here are proposals for Unicode character and UTF-8 modules.  They were
part of my camomile library, and passed the random tests.

I do not know the coding convention of Extlib.  So, I am virtually
certain that there are many point that must be fixed.

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] Array interface

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

On Tue, 17 Jun 2003, John Skaller wrote:

> I finally managed to get hold of the archive.
> If you want to make me a developer I can contribute to the documentation.
> 
> Comments. DynArray.make size null: makes an array of length zero,
> with size element slots initialised by null.
> 
> Can't you initialise the empty slots with Obj.magic(0)?

No.  What if it's an array of floats, which is unboxed?

> I don't want to put an element here. I may not have a
> convenient default, and even if I do it is going
> to kill performance compared to an integer, since
> there will be a bogus pointer for the collector to
> chase down.

If you don't have a convient default, use a 'a option Dynarray.t.  That 
gives you a convient default- None.  I didn't want to always use options 
in the array, because in many cases you don't need them, cases where there 
are sane, or at least usable default values (0, nan, "", false, etc).

Note: in the current API there is no way to get access to an element with 
a null value.  So you don't ever have to worry about distinguishing null 
values from sensible values.  So it's still safe if the null value would 
otherwise have meaning.

> 
> Also, I haven't checked the collector header,
> but isn't there a count field that can be
> used for the count without compromising the
> allocator's knowledge of the length of a block?
> [The size may be needed for disposal and/or movement
> on compaction] If there is, the store can be
> totally uninitialised, which is even more efficient.

I haven't checked, but the idea of using uninitialized memory with a 
garbage collector makes me nervous.

Brian