Ouch.

I bow to your superior experience.

Is there a syntax which makes treatment of options easy?  That is, if
about every other line of my library is an action on objects from this
array, is there a convenient way to use options without cluttering up the
code?

I can't use your second solution, because the objects in the heap may be
difficult and expensive to construct, and may have side effects (for
example, in one instance they are handles to processes; in another they
are handles to Libevent events).

Mike

On Sat, 23 Jul 2005, Xavier Leroy wrote:

> > I was constructing a binary heap of tuples the other day.  After pondering
> > these options, I just used Obj.magic 0 as the null value in the array.
> > The heap was in a module, so nothing else could see the array, and I could
> > prove that the code never accessed the null elements, so the use of
> > Obj.magic seemed justified.
>
> In other terms:
>
> " I was walking in the city the other day.  I saw a syringe lying on
>   the sidewalk.  I stuck the needle in my forearm.  That was a classy
>   neighborhood, so the use of the syringe seemed justified. "
>
> Sorry for being sarcastic, but I strongly feel that any suggestion
> to use Obj functions should be avoided on this list.  The OCaml
> compiler performs some type-dependent optimizations that can result in
> incorrect code (w.r.t. GC invariants) if wrong types are given using
> Obj.magic.
>
> 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.
>
> A few years ago, I spent one full day debugging a mysterious crash
> in code provided by a user, then realized that the problem was exactly
> the use of Obj.magic outlined above.  I then swore to throw away all
> bug reports whose repro case uses Obj.  So, you can break the type
> system with Obj, but you get to keep the pieces afterwards.
>
> Coming back to the initial question, I would first warn against
> premature optimization: quite possibly the overhead of the "option"
> solution is negligible.  If not, just ask the user to pass an initial
> value of the heap element type to the "create heap" function.
>
> - Xavier Leroy
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>