User model: terminology

[Stephen Colebourne]

On Wed, 4 May 2022 at 16:06, Brian Goetz <brian.goetz at oracle.com> wrote:
Overall, things are looking positive in Valhalla.

I agree 100% with Kevin's document, particularly the initial
definitions of Values, Variables, Containers, Kinds of Values and the
essential characteristics of Objects.

I still believe there is a profitable direction of thought in
imagining what Java would be like if references were visible in source
code:

class Person {
  private ref<String> name;
  private ref<LocalDate> birthDate;
  private int customerScore;
}

This way of thinking makes it more obvious why == does what it does
for example. I still think it would be worth exposing an actual
`ref<T>` type as part of Valhalla as it helps join the whole model in
people's minds, and allows null to be managed better (maybe it is just
a new name for `Optiona<T>`?.


I'm onboard with the idea that authors can opt-in to accepting
non-atomicity, although I worry that it will be overused and not
properly understood. I'm also onboard with the idea that authors can
opt-in to accepting that zero-is-ok. I think that both are significant
problems, thus I want both the syntax and defaults to reflect the safe
choice (B2 safe-atomicity zero-not-ok).

>      class B1 { }                 // ref only
>      value class B3 { }           // ref and val projections
>      value-based class B2 { }     // ref only

Given the above, while this reads very nicely, it runs far too big a
risk of exposing bad zeroes.


>   - A term for all non-identity classes.  (Previously, all classes had identity.)

After reading Kevins document I'm a bit wary of using "value" for this
term. Because as per the document, values have a quite specific
meaning in the value-variable-reference model, and I think "value
class" might well be muddying the water. "inline" is OK, but a bit
meh. "primitive" isn't right at all.

I'd like to propose "struct" :

  public class B1 {...}
  public struct B2 {...}

I know that "struct" has some baggage and is usually used for a
compound set of fields, but I don't see any particular reason why it
couldn't fit here. As a word it evokes ideas of a "bundle of memory"
and "being passed around without overhead". It goes nicely in text and
code.

I actually think it is better to *not* use "class" here. Java already
has a thing where one declaration produces multiple classes - enums,
and we generally call them "enum", not "enum class". This is another
reason not to use "value class".

> - A term for  what we've been calling atomicity: that instances cannot
> appear to be torn, even when published under race.  (Previously, all
> classes had this property.)

I'd like to propose "raw" for this term (non-atomicity). I've used it
in my mental model for a few days and it seems to work quite well. IMO
"fragile" or "unsafe" don't quite fit with what I'd expect from a
programming language term. "non-atomic" would be OK, but is a bit
verbose.

  public raw struct B2a {...}

Some phrases:
 "All existing primitives are raw"
 "The JVM may choose to treat a struct as raw even if not defined as
such, but only where it can prove it is safe to do so."

I don't think there is any need to mention raw at the use-site, but if
there was it works well - `Complex.raw c = ...`

>   - A term for those non-identity classes which do not _require_ a
> reference.  These must have a valid zero, and give rise to two types,
> what we've been calling the "ref" and "val" projections.

To me, the term "primitive" is most closely associated with the fact
that zero-is-ok and that there are two projections (int and Integer).
Thus I think the term here is "primitive".

  public primitive struct B3 {...}
  public raw primitive struct B3a {...}

Although there is a case for dropping "struct" in code, the *term* is
clearer with struct. Saying "primitive struct" clearly delineates them
from the original primitives.

For naming, I would say that ".ref" type would get the good name,
leading to ".primitive" as the projection (or perhaps ".val"). A type
aliasing feature could then be used:

  alias int = Integer.primitive
or
  public primitive int struct Integer {...}

I prefer aliasing as it is needed to make sense of the int/Integer
char/Character mess we already have.

HTH
Stephen