On 13 Dec 2021, at 19:05, Kevin Bourrillion wrote:
> …
> Yes, in general I am sure that I can't accomplish actual ground up
> non-cyclical definition-definitions here. I think it should suffice to be
> descriptive enough for the reader to course-correct their previous notions
> in this direction
>
> On 13 Dec 2021, at 18:40, John Rose wrote:
>
> > Another (more subtle) stress to your terminology is your assertion that
> a mutable variable “forgets” the previous value when a new value is
> stored. That isn’t strictly correct in the case of race conditions. Only
> a volatile variable
Two more thoughts: You could get away with saying “indivisible unit”; I think
that would convey much of what you mean. Also, a footnote drawing the reader’s
attention to native hardware types (long, byte, float, reference) would make it
clear that a Java computation is meant to “bottom out”
I have some comments. Since the doc invites directly stuck-on comments, I’ve
requested edit permission, as that seems necessary for me to stick on a comment.
Some free-floating notes:
Good use of “freely copyable” as a concept. There’s a tough case, happily not
relevant to Java, of linear
Hi,
So I've been threatening for a long time that I've been hard at work
writing up a coherent conceptual model for "how data looks/works inside a
running Java program today". I have a few purposes for it, but one is to
form a basis for explaining "and now here's precisely what parts Valhalla
