- (the controversial one) Atomicity is simply too confusing and
potentially astonishing to piggyback on "primitive-ness" or
"reference-ness" in a codes-like-a-class world.
(Controversial with me at least; I keep thinking who are these people
who can understand the rest of how to safely write non-locking
concurrent code yet would struggle with this?)
So, the reason I'm being so dogmatic about this is that it undermines
the belief that "immutable classes are always thread-safe". I think the
"objects vs values" distinction is too subtle; hiding atomicity behind
primitive-ness is too subtle. I can get behind saying "immutable
classes are always thread-safe, unless they have been explicitly marked
as non-atomic", because this is a clear indication that can't be
confused for anything else.
Would I be right that we can achieve primitive unification even
without B4? There is nothing wrong with our delivering many
performance gains while leaving others on the table for later.
Yes, delivering primitive unification first means you can't have
flat Complex yet.
But they still get /often-flat/ Complex? Sounds like
/always-flat/ Complex is the perfect thing to punt on then.
They'll get flattening on the stack, but the layout of a Complex[] will
likely be an array of pointers for a long time, until some heroics kick
in. I don't necessarily have a problem with a phased delivery where
flattening comes later, but I'll note, too, that this is where *most of
the heap flattening win is* -- arrays of nontrivial numerics. Because
there are lots of them, and such code will likely iterate over the
arrays plenty, doing small amounts of CPU work per element, and then
stalling when the memory subsystem chokes on a cache miss. So we can't
punt for that long.
