This is really great stuff. I think that figuring this out and incorporating it into idiomatic Julia code would be a really great step forward in writing code that's fast AND safe.
I really liked your thoughts during JuliaCon regarding the difference between Epistemological missingness(Absence of knowledge of value, but value exists) and Ontological missingness (Value does not exist) [1]. Is there a reason that this Option type is better suited to cover the former, and not the latter? Maybe a couple usage examples of OptionTypes would also help clarify the use cases you're shooting for. [1]: https://github.com/JuliaCon/presentations/tree/ecfe2396010dad76f472a7eaacf4ada8523b65a1/RepresentingData peace, s On Thu, Jul 31, 2014 at 10:31 AM, John Myles White <[email protected] > wrote: > Also worth noting that our goals are somewhat different from Boost’s: we > aren’t trying to express the notion of an uninitialized value, but rather > than notion of a value whose unquestionably well-defined value is not known > to the program. This is not quite the logic of things like Haskell’s Maybe, > but we’re co-opting some of their terminology. > > — John > > On Jul 31, 2014, at 7:28 AM, Júlio Hoffimann <[email protected]> > wrote: > > 2014-07-31 11:10 GMT-03:00 John Myles White <[email protected]>: > >> At JuliaCon, I described the idea of using Option types instead of NAtype >> to make it easier to write type-stable code that interacts with NA’s. To >> help facilitate a debate about the utility of this approach, I just wrote >> up a minimal package that implements Option types: >> https://github.com/johnmyleswhite/OptionTypes.jl >> >> Essentially, an Option type is a scalar version of a DataArray: it >> contains a value and a Boolean mask indicating whether that value is NA or >> not. Because Option types are parametric, they allow us to express the >> variants of NA that R has, such as a Float64 specific NA and an Int64 >> specific NA. >> >> — John >> > > Dear John, > > I'm joining the debate late, but the Boost C++ devs did make a good review > of models for optional types and came up with a quite consistent API: > http://www.boost.org/doc/libs/1_55_0/libs/optional/doc/html/boost_optional/development.html#boost_optional.development.the_models > > Are you following their work? Don't you think Optional would be a better > name for it? > > Best, > Júlio. > > >
