sentinels & who owns the value space Re: valhalla-dev Digest, Vol 17, Issue 10
twhitmore.nz at gmail.com
Sat Dec 19 05:45:41 UTC 2015
Great example. Thanks for being specific, Mohammad.
Your example illustrates the use of additional storage (the
*zeroToThirtyOne* field, etc) as an auxilliary to provide sufficient
representation to distinguish known sentinels from valid client values.
I would agree that this design might be harder to apply generically to
arbitrary value types, but I'd presume it works for any integral types
having >2 values (it doesn't exactly fail for boolean, representation
become entirely auxilliary though).
My thinking on Valhalla has emphasized "abstracting" the difference between
types (reftypes, primitives & value types) and allowing existing idiom &
usage to be expressed in an abstract way; my feeling being that building
capable abstractions over 'any' type, would give a stronger foundation that
needing to lean on programmatic specialization.
I previously proposed having the language offer both "T.default" and
"T.sentinel" as distinct values -- to represent the two distinct uses of
null better in eg. integer space. Null can be a default and 0 is a good
default; null can also be a sentinel, but Integer.MIN_VALUE is a much
better sentinel than 0 :)
I guess what I'm working to is, that having the language provide two
abstracted values -- 'default' and 'sentinel' -- which are distinct, could
be used as the two cell sentinels for your hashset & special-cased in the
add/ contains check etc.
This would be extensible to value-types by the component fields being set
to default/ or sentinel appropriately. The only problem is ref-types, which
in my proposal would have both RefType.default == null and RefType.sentinel
== null; and would thus not be amenable to providing your two separate cell
Thanks for your thoughts.
More information about the valhalla-dev