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.
