On Thu, 15 Jul 2004, John Carr wrote:

> > 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
> 
> So use true 0 as opposed to the integer 0 internally represented as 1
> to mean "None".  This adds some complexity but may be worth the effort
> as options are common.

What's the representation of Some(None) then?  The Some() goes away, and 
the containing value is unboxed- it turns out to be the same as just None.  
There is no way to differentiate Some(Some(Some(Some(None)))) from None.

Which I mentioned in my original post.

I can see three ways around this.  First, just change the behavior, 
probably adding a switch into the compiler to issue a warning whenever it 
sees a type of the form 'a option option.  This would be under the 
assumption that very little code actually does options of options (I don't 
think I've seen any- not to say it doesn't exist, just to say it's not 
common).  Second possibility, have the compiler detect when it's doing an 
option of an option, and forcibly insert boxing at that point.  Third 
possibility: create a new type, 'a nullable, that has this as the defined 
behavior.

I've seen designs contort themselves in an attempt to avoid the overhead 
of boxing options- starting with enums in ExtLib.  This is an overhead 
which doesn't have to exist, and we should at least consider eliminating 
it.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
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