Thanks Dan! On Mon, Apr 25, 2022 at 10:47 AM Dan Heidinga <heidi...@redhat.com> wrote:
And I'm unclear on why the ephemeral information presentation is > prefered to the Platonic meaning? > Indeed I've gotten this feedback before too. My response was that it's not so much that one is "preferred", as that there just isn't much to say about the other. 42 as a Platonic concept just sort of ... is? But as a piece of *information* we can trace its flow throughout the code. There is always some source speaking it and some sink hearing it (modulo StatementExpressions). Frankly I don't know the terminology that people who do data flow analysis would use here, but toward my goal of having a clear picture of "what's happening inside my program" (that's at least a level higher than things like registers), I've found this mental picture helpful. *What* is it that gets lost by a StatementExpression, or by a second write to a variable with no read in between? We came to see those as cases of "value not used" in a very analogous sense to our long-existing checks for "variable not used". Or in nullness analysis we have been looking at "where can a null value flow in, and where can it flow out". Each "flowing" or whatever that happened is of interest. You could probably say that the thing I'm really describing is a single "transmission" of a value and not a value itself. I do I agree that there is *something* a little off about my presentation here. I'm slightly concerned about the presentation of "small" as being > incidental. While size isn't a critical factor from the programming > model perspective, it is incredibly important for aligning with the > natural physics of the hardware. > > The fact that these are "small" (at most 64 bits) is incidental, not > essential; introducing a new quadruple type would not destabilize our > concept of a primitive value. > Good point, thanks. Obviously I'm only attempting to pave the way for seeing that compound values are still values, but I certainly don't mean to imply we'd ever want a value that's 1000 bytes long. Upon looking at it again, this text just seemed unnecessary and so I've nuked it. > On Fri, Apr 22, 2022 at 6:38 PM Kevin Bourrillion <kev...@google.com> > wrote: > > > > I'd like to remind everyone about this (self-important-sounding) > document I shared some months ago: Data in Java programs: a basic > conceptual model > > > > I may have undersold it a bit last time. True, it's not the final word > on the only possible conceptual model anyone could ever form; however, it > is at least a very extensively thought-out and reviewed and self-consistent > one. I've also revised it a lot since you saw it (and it's still open for > review). If nothing else, at least when I make arguments on this list you > don't have to wonder what they are based on; I've laid it all out in black > and white. And on that subject... > > > > The crux of that doc for Valhalla purposes is its clear separation > between objects and values as wholly disjoint concepts. > > > > An object: has its own independent existence; is self-describing, thus > can be polymorphic; is always indirected / accessed via reference; is > eligible to have identity. > > > > A value: has no independent existence; is container-described, thus is > strictly monomorphic; is always used directly / inline; cannot have > identity. (Yes, I'm glossing over that references are also values, here.) > > > > What unifies objects and values (setting aside references) is that they > are all instances. > > > > (First, to parrot Brian of a while ago: for a primitive type, the values > are the instances of the type; for a reference type, the values are > references to the instances of the type, those instances being objects.) > > > > Some instances are of a type that came from a class, so they get to have > members. Some instances of are of a type that never used to have a class, > but will now (int, etc.) -- yay. And some are of array types, which act > like halfway-fake classes with a few halfway-fake members. Members for > everybody, more or less! > > > > Though we have at times said "the goal of Valhalla is to make everything > an object", I claim the unification we really want is for everything to be > a class instance. I think that gives us enough common ground to focus on > when we don't otherwise know which thing the thing is (e.g. with a type > variable). > > > > One thing I like very much about this is that it fits perfectly with the > fact that Integer is a subtype of Object and int is not. > > > > The way I think bucket 2 can and should be explained is: "in the > programming model it absolutely is an object. In the performance model, the > VM can replace it undetectably with a (compound) value. But that is behind > the scenes; it's still behaviorally an object and don't feel bad about > calling it an object." To me this is very simple and sensible. > > > > If we instead want to say "the int value 5 is an object now too", then > we have some problems: > > > > * I think it ruins those clean explanations just given > > * we'd need to coin some new term to mean exactly what I've just > proposed that "object" mean, and I have no idea what that would be (do you?) > > > > What are the latest thoughts on this? > > > > -- > > Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com > > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
