sentinels & who owns the value space Re: valhalla-dev Digest, Vol 17, Issue 10

[Thomas W]

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

Thanks for your thoughts.

Regards,
Thomas