Version française
Home     About     Download     Resources     Contact us    
Browse thread
How to do this properly with OCaml?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Stephane Glondu <Stephane.Glondu@c...>
Subject: Re: [Caml-list] How to do this properly with OCaml?
On Sunday 24 July 2005 17:32, skaller wrote:
> Not if the collector is modified by INRIA to support variable
> length arrays: this is some kind of tagged block with
> a mutable length count which limits how far along the block
> the collector looks for boxes: the length count is less
> than or equal to the actual number of allocated slots.

It would surely be interesting. But now, we have moved from "using 
Obj.magic for better efficiency" to "modifying to collector"...

> I am not so sure: to initialise an array causes a store
> in each slot, which forces the whole array to scroll
> through your cache: if the array is big this means
> disk paging/swapping activity.
>
> Why do all that when the values will never be read?
> We do not even know in advance how much of the
> array will actually be used. Consider an array
> of length 10,000 elements, where only 100 are used.
> We allocate space for 10,000 because we're conservative
> and want the program to run on many sized data sets.

I was just saying that the GC will go through all your array anyway, even 
if you use only the first 100 elements (as far as I understood).

> BTW: this is a *real* issue an Ocaml user had.

I agree.

> Think of a class type, whose constructor function itself
> takes other class values as arguments .. it can be quite
> complicated to set up such values, and, worse,
> Ocaml being imperative doing so may have side-effects.

You can make a dummy class object with dummy methods without using your 
class definition (class typing is done only with the set of methods). 
However, I agree this is not satisfactory.

> However that turned what in C is a trivial set of
> library functions into a complex unreliable mess
> and left me wondering whether the encoding was
> properly transparent.

I agree that strongly-typedness makes things more intricate sometimes, but 
it will not make me prefer C... :-)

> Not just huge values: values that contain references
> to other values .. such as in a graph .. occupy
> a lot of memory.

That is what I mean by huge values.


BTW, for some purposes can also use another datatype such as a Map or a 
Set. They do not involve such problems, are quite efficient, and more 
enjoyable than in C...


-- 
Stephane Glondu.