Question on layer/peeling

[Michael Barker]

>
> The layer part is indeed not yet implemented.  But even a catalogue of
> where the code can't be made value-clean would be a useful contribution.
> We know that the Collections implementation is full of stuff that will be
> hard to any-fy without help from layering or other tools, but don't yet
> have a complete catalog.
>

I think I've managed to hit the wall with the current implementation of
Valhalla.  I think the "implementation by parts" work or something similar
needs to make progress before moderately complex collections like HashMap
can be implemented.  So, sticking points thus far.

1) Nulls - checking against null inputs.  Ideally no-op and always true for
values.
2) Nulls - nulling out reference array elements.  Need some notion of
"zero" for value types, so that nested value types containing references
don't leak memory.
3) Methods from Object, e.g. hashCode and equals.  At the moment an <any T>
doesn't have any methods, there's no obvious way to get the hash code of,
or equate any-type variables.

#1 & #2 can be worked around by simply not doing them and suffering the
negative effects (NPEs and memory leaks respectively).  I can't find an
easy way to work-around #3.  It was mentioned that value types will need to
define hashCode/equals/toString.  If this is the case, should the existing
primitives support them too, such all possible types of an any-typed
variable supports said methods?  Obviously this impacts a HashMap
implementation heavily as it is all about the hashCode and equals, but
would probably impact an array ArrayList implementation too as it requires
equals to support contains.

Mike.