Re: [Ocaml-lib-devel] Array interface

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

Brian Hurt wrote:

> On Fri, 20 Jun 2003, John Max Skaller wrote:

> 
> It is both fair and true.  Notice that the examples I gave, all except
> void* were unboxed.  I don't know how many C++ compilers can figure out
> that a Vector<foo*> and a Vector<bar*> can use the same object code.  


You didn't understand. They ALL can.
Because it doesn't require any work by the compiler at all.
It is the CLIENT that does it:

	template<class T> class vector<T*>
	{
		T* get(i) { static_cast<vector<void*> >(*this).get(i); }
	...
	}

All the compiler has to do is inline the get method call,
which consists exclusively of type casting, and then
dispatching to the common routine used by vectors
of T* for all T.


>>The principal problem in C++ here is the lack of
>>a garbage collector. 
>>
> 
> If this is the only reason you're using Ocaml and not C++, take a look at:
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/
> 
> Or you might take a gander at this language:
> http://java.sun.com/
> I hear they're adding both templates and operator overloading in the next 
> version.


Don't be silly. I said "the principle problem in
C++ *here*" refering to the context of discussion.
I meant: a vector of pointers in C++ isn't a substitute
for a vector of T, because of memory management issues.

You can do the very same trick for handles as raw
pointers in C++, but that still won't handle recursive
data structures ..

> Don't have casts in Ocaml. 


you have Obj.magic, which is a cast.

> I don't know of a way to force unboxing of
> floats in an array without coding in C.  


There is no need to do that. The proposal is
to make an array of ints. And cast input values,
all of which are boxed, to int. And cast
values being fetched into single values,
all of which are boxed.


If I could do that, Obj.magic()  
> would work.  So we're talking about rewritting the whole thing in C.  
> Could be done.  Don't use ints for the array type, use the Value type.  


Ok.

 
> But one of the reasons I'm contributing to ExtLib is that I want to do 
> some programming in *Ocaml*.  But I'm willing to take it under advisement, 
> and put it on my to do list.  Just don't hold your breath.


I agree, it would be nice to do everything in Ocaml.

But this is a fundamental data type it seems we cannot do
in Ocaml.

The null value is not acceptable at all. Just suppose
that you wanted to use a Dynarray.t to implement
some part of another polymorphic container ..
then you would have to pass the null value to IT too.
So the null value 'permeates' any data structure
you use it in. For example a list which automagically
converts to an array to improve performance.

So if it is necessary to do a C implementation,
then do one, because it will make Ocaml
programming so much easier.

I need a dynamic array. I'm using lists far too often.
I can implement it in Ocaml easily as an array ref,
but I'd have to copy the array on *every* append
operation.

> And are you willing to gaurentee that no one will ever care that float
> Dynarray.t's are boxed?  "But float arrays are unboxed!  This makes all my
> data structures 50% larger than they need to be!  Bloat!  Horror!  
> Dynarrays should work just like arrays, but dynamic!"


I can't guarrantee that, I'm just saying that if I have to

choose, the null value's got to go. I won't use Dynarray
otherwise, its already annoying to have to fill an
array with a dummy value when I then immediately
fill it with some other data: I can get around that
with function, but it is often very inconvenient
to have to wrap procedural code up.

An important advantage of Dynarray is that it doesn't

do gratuitous initialisations: neither wasting time
nor requiring a dummy value.


> Brian, who is snarly because he's having to wade through some atrocious 
> C++, and isn't in the mood to listen to people sing hosanahs to the 
> language.

You have my sympathy. I have recently been blasting the
committee about the mess. But I'm on it, I'm entitled :-)
I'm not claiming C++ is a good language, especially
compared to Ocaml. I'm just commenting that in this
area, it is much better at handling unboxed
data types, and therefore often can generated
more efficient code. You are right that means
*more* code, and also that in general, it
instantiates needless duplicates of the same
code... for example, the vector<void*>
will often do for vector<int> on a Unix machine.

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