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” in operations on units of data familiar to assembly programmers. They are indivisible units, but even more important, their operations are natural to real computers.
On 13 Dec 2021, at 18:40, John Rose wrote: > 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 types (IIRC Rust has them) where a value is > freely copyable, but only to the extent that the source forgets the value > after the sink gets it. Accounting for that would stress your terminology. > > 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 reliably “forgets” its previous value in the presence of races. > > You don’t actually define the term “value” but just illustrate it and make > claims about it. Maybe you have to do it that way… Actually, you say it’s > “unit of data”. Referring to “data” as a known term (for readers who are > programmers) is OK. > > Saying “unit” is more mysterious. You certainly don’t mean units of measure, > or functional programming unit types. Are you meaning to imply that it has > no subparts which might also be termed units? That’s OK as long as you have > today’s primitives (which I like to call “scalar primitives”) and of course > references (which are also scalars). By “scalar” I mean an item of data that > is not composed of further scalars.
