basic conceptual model

John Rose john.r.rose at oracle.com
Tue Dec 14 02:44:59 UTC 2021


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.


More information about the valhalla-spec-observers mailing list