Re: [Caml-list] How to do this properly with OCaml?

[Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>]

On Sat, 23 Jul 2005, Xavier Leroy wrote:

> For instance, the following implementation of "magic" arrays will
> eventually cause the GC to crash:
> 
> type 'a t = int array
> let get (a: 'a t) i = (Obj.magic a.(i) : 'a)
> let set (a: 'a t) i (x: 'a) = a.(i) <- (Obj.magic x : int)
> 
> while the same code with "string" instead of "int" will not.  You
> don't understand why?  Then, don't use Obj.magic.

Could this be for precisely the same reason why I used Obj.magic (1,2) 
where Michael suggested using Obj.magic 0? I suppose Obj.magic () 
also would not work, right?

> Coming back to the initial question, I would first warn against
> premature optimization:

I do not think this is premature optimization in that particular case. The 
code I am talking about is quite mature and performed very well for years 
in its Lisp incarnation - I am just right now transliterating it to 
OCaml, as I need it there.

Another low-level question: it seems to me as if it were a piece of cake 
to build a C-linkable shared object library that in all respects looks 
like any old C .so library, but internally uses code that was compiled 
from OCaml.

However, in order to get there, I had to ar x libcamlrun.a and 
ld a new libcamlbytecode.so shared object from the pieces. It may well be 
that I just missed something in the documentation due to my own 
stupidity/ignorance, but so far it seems to me as if this were 
tremendously useful, but somehow not documented very well.

Anyway, as I clearly do appreciate the option to build C shared objects in 
something better than C, I wonder whether I can rely on being able to do 
that trick with future versions of the OCaml compiler as well.

> quite possibly the overhead of the "option" solution is negligible.

For a lot of applications this is indeed right. However, for the 
particular one I have in mind right now, I am more or less competing
with C code, so I am indeed a bit worried about that extra indirection.

> If not, just ask the user to pass an initial
> value of the heap element type to the "create heap" function.

Well, that's also not that beautiful, but at least, it would work.

But coming back to:

> while the same code with "string" instead of "int" will not.

Can I take this as a guarantee that will also hold for later versions of 
the compiler? Just for my particular private application - not that I 
would advise or teach anyone to use such a technique, or distribute any 
code in compiled or source form that makes use of it.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)