Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[Jacques GARRIGUE <garrigue@kurims.kyoto-u.ac.jp>]

From: John Prevost <j.prevost@gmail.com>

> On Thu, 15 Jul 2004 10:38:14 -0500 (CDT), Brian Hurt <bhurt@spnz.org> wrote:
> > One of the problems with returning error conditions instead of throwing
> > exceptions is the cost of boxing a 'a option.  I'd like to advocate for
> > the idea of unboxing 'a options.
> 
> This has been discussed before.  The essential problem is this:
> 
> Currently:
> 
> type 'a option is not the same as type 'a option option
> Some Some 1 is not the same as Some 1
> Some None is not the same as None
> 
> With unboxed options:
> 
> type 'a option is the same as type 'a option option
> Some Some 1 is identical to Some 1
> Some None is identical to None

I answer before the discussion goes hairy (it already has.)

We know perfectly how to unbox options. This is described for instance
in my paper with Jun Furuse on optional arguments.
  http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/rims-1041.html

The idea is just to reserve a sufficiently large memory area to
represent every needed (Some (Some ...(Some None) ...)).
You don't even need to access this area (it might not be physically
mapped.)
Then all values of type (t option) are represented either by a pointer
to this area, or by the wrapped value itself (if it is not an option.)

I believe Xavier implemented this trick once, but this has some small
cost for both wrapping and unwrapping (you must check whether the
value is a pointer to this area), so that there is no clear
advantage compared to allocating a block for each Some. Keep in mind
that most options are short-lived, so they will be allocated in the
young generation, and disappear with the next GC. Such a pattern has a
very low cost: just check the allocation limit once in a while. And of
course there is no cost for the None case.

Conclusion: this is not worth bothering about, and optional
implemented in the current way are efficient enough, thank you.

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners