Stream: t-lang/wg-unsafe-code-guidelines

Topic: Finding terminology


RalfJ (Nov 04 2018 at 10:35, on Zulip):

We could use some more eyes on https://github.com/rust-rfcs/unsafe-code-guidelines/pull/40 to come up with a name for the thing that we sometimes call an "rvalue", an "operand" or just a "value" in Rust currently -- the thing that gets stored in a place; the thing that is denoted by the right-hand side of an assignment operation. :)

RalfJ (Nov 04 2018 at 10:38, on Zulip):

("value" is a bad term because for many of us -- those coming from FP or PL -- a "value" is just the result of a computation. So it doesn't make any sense to call the 3+2 in x = 3+2 a value. The term value, for us, is to distinguish from "expression" or "computation" -- it's about being the result vs. the instructions that can be executed to compute said result. So we can have "place expressions" like &x.field which then compute to a "place value" like { pointer: 0x002345f0, alignment: 4 }. The "place" vs "rvalue" distinction is on an orthogonal axis, this is about whether we are computing a location in memory that we can store some data in, or whether we are computing the data that is to be stored somewhere.)

gnzlbg (Nov 04 2018 at 10:39, on Zulip):

I find the discussion hard to follow, and also am a bit confused about how these are called in other languages. The "value cartegories" in C++ change pretty much with every std

RalfJ (Nov 04 2018 at 10:39, on Zulip):

Yeah I propose we ignore the mess that C++ made there, other than using it as a bad example

RalfJ (Nov 04 2018 at 10:40, on Zulip):

lucky enough, I think in rust we just have these two ("place" vs the to-be-named thing). C++ got a way more categories (must be a dozen by now), I suppose due to its approach to "move semantics". (CC @Nicole Mazzuca)

gnzlbg (Nov 04 2018 at 10:41, on Zulip):

For me personally, separating "memory" from "objects" is what makes most sense, but that might not be strict enough to be useful

RalfJ (Nov 04 2018 at 10:41, on Zulip):

what do you mean? (FWIW I also favor "object" currently as the term)

RalfJ (Nov 04 2018 at 10:42, on Zulip):

so 3+2 would be an "object expression" denoting the "object" 5

gnzlbg (Nov 04 2018 at 10:42, on Zulip):

3, 3+4, ... are expressions producing objects
let x = 3; x is an expression reading the object from the "memory" at x

gnzlbg (Nov 04 2018 at 10:42, on Zulip):

you can take an address to an object in memory, but the object produced by 3+4 is not in any memory

RalfJ (Nov 04 2018 at 10:42, on Zulip):

the latter is place-to-object conversion, which rads the object from memory if that's where it is. I agree.

gnzlbg (Nov 04 2018 at 10:42, on Zulip):

so &x is "ok", but &(3+4) would not be

RalfJ (Nov 04 2018 at 10:42, on Zulip):

in miri, objects can be either in memory or "immediate"

RalfJ (Nov 04 2018 at 10:43, on Zulip):

&(3+4) is okay in Rust though :P

RalfJ (Nov 04 2018 at 10:43, on Zulip):

but it desugars to something where a place is involved

gnzlbg (Nov 04 2018 at 10:43, on Zulip):

i know, so to make that ok we need to define in which memory it is

RalfJ (Nov 04 2018 at 10:43, on Zulip):

well we can just apply our definitions after desugaring

RalfJ (Nov 04 2018 at 10:43, on Zulip):

then all is easy

RalfJ (Nov 04 2018 at 10:44, on Zulip):

let _tmp = 3+4; &_tmp is what happens

RalfJ (Nov 04 2018 at 10:45, on Zulip):

so we first evaluate the object 3+4 to the object value 7, then we store that in the place _tmp, and then we do place-to-object conversion (&), which proceeds by computing the place value (which is an address in memory and some more information like alignment), and then turning that into an object value (the location in memory; the alignment gets discarded)

gnzlbg (Nov 04 2018 at 10:53, on Zulip):

yeah, that makes sense to me. IIRC ubsan does not like the term "object", but I don't find it is confusing due to "trait object"

RalfJ (Nov 04 2018 at 10:57, on Zulip):

Yeah, let's see what @Nicole Mazzuca thinks. I also wonder if @nikomatsakis has any thoughts.

Nicole Mazzuca (Nov 04 2018 at 15:42, on Zulip):

1) no. object is a bloody awful term. It is both overloaded by OO languages, and means exactly the opposite of what you want it to mean.

Nicole Mazzuca (Nov 04 2018 at 15:44, on Zulip):

2) there are three categories of expression in C++ - lvalue, xvalue, prvalue. There are two kinds of category; glvalue = {lvalue, xvalue}; rvalue = {prvalue, xvalue}. A glvalue is an expression which refers to an object, as opposed to just a value; and an rvalue is an expression which can be bound to an xvalue reference (i.e., you can coerce a prvalue into an xvalue).

Nicole Mazzuca (Nov 04 2018 at 15:50, on Zulip):

3) please just call it value vs place. It's really not that hard. A value is what one operates on - something like 5 or "hello" or ("boop", 2). A place is a location, value pair - a "place" that one can put a "value".

RalfJ (Nov 04 2018 at 15:59, on Zulip):

3.) no. a value is something else for a significant chunk of our community -- in particular for the chink that has most experience with anything formal.

RalfJ (Nov 04 2018 at 16:00, on Zulip):

just because C/C++ use "value" the wrong way doesnt mean we should

Andrew Poelstra (Nov 04 2018 at 16:00, on Zulip):

In C the word "object" is pretty close to what we're referring to

Andrew Poelstra (Nov 04 2018 at 16:00, on Zulip):

C++ uses it to mean "instance of a class" like in Java, which was a weird decision because it was very divergent from C

Nicole Mazzuca (Nov 04 2018 at 16:00, on Zulip):

@RalfJ I don't agree? I use value to mean exactly the same thing in OCaml and Haskell.

RalfJ (Nov 04 2018 at 16:01, on Zulip):

you suggested in (3) above to call 3+4 a value

RalfJ (Nov 04 2018 at 16:01, on Zulip):

it is not

Nicole Mazzuca (Nov 04 2018 at 16:01, on Zulip):

@Andrew Poelstra no - C++ uses object like C uses object

Nicole Mazzuca (Nov 04 2018 at 16:01, on Zulip):

@RalfJ 3 + 4 is a value expression - an expression that results in a value

RalfJ (Nov 04 2018 at 16:01, on Zulip):

"value expression" just makes no sense

Nicole Mazzuca (Nov 04 2018 at 16:02, on Zulip):

yes it does?

RalfJ (Nov 04 2018 at 16:02, on Zulip):

ocaml+haskell do not have this distinction between places and "objects". they have expressions and values, done.

Nicole Mazzuca (Nov 04 2018 at 16:02, on Zulip):

7 is a value which 3 + 4 results in

RalfJ (Nov 04 2018 at 16:02, on Zulip):

once you have places and "objects", you have 4 kinds of things as they both are written down as expressions and evaluate to some kind of value

Nicole Mazzuca (Nov 04 2018 at 16:02, on Zulip):

OCaml absolutely has this distinction, because they have ref

RalfJ (Nov 04 2018 at 16:02, on Zulip):

ocaml has ref but doesnt need places

Nicole Mazzuca (Nov 04 2018 at 16:03, on Zulip):

that's what a ref is - a place

RalfJ (Nov 04 2018 at 16:03, on Zulip):

there are just values of type ref, that's enough. this is because ocaml does not have the & operator.

Nicole Mazzuca (Nov 04 2018 at 16:03, on Zulip):

look, please at least try to understand

RalfJ (Nov 04 2018 at 16:04, on Zulip):

I get the feeling you are not trying to understand

Nicole Mazzuca (Nov 04 2018 at 16:04, on Zulip):

I'm trying to use reasonable language that people from other systems languages would understand

RalfJ (Nov 04 2018 at 16:04, on Zulip):

I am trying to use reasonable language that people from other functional-style langauges would understand

Nicole Mazzuca (Nov 04 2018 at 16:05, on Zulip):

Rust isn't a functional-style language

RalfJ (Nov 04 2018 at 16:05, on Zulip):

your terms are already used in my community and they mean something different. I acknowledge "object" is already used in your communicty so I am looking for something else.

RalfJ (Nov 04 2018 at 16:05, on Zulip):

it is fucntional enough to start using such terminology. it is expression based. it is not really less functional than ocaml is.

Nicole Mazzuca (Nov 04 2018 at 16:05, on Zulip):

that's just untrue?

Nicole Mazzuca (Nov 04 2018 at 16:06, on Zulip):

"functional" is in how you write code

Nicole Mazzuca (Nov 04 2018 at 16:06, on Zulip):

"expression-based" is a nice feature for any language

Nicole Mazzuca (Nov 04 2018 at 16:06, on Zulip):

and also, it's not like value is an overloaded term here.

Nicole Mazzuca (Nov 04 2018 at 16:06, on Zulip):

it means exactly the same thing in OCaml as it does here

RalfJ (Nov 04 2018 at 16:07, on Zulip):

no and I explained above why

Nicole Mazzuca (Nov 04 2018 at 16:07, on Zulip):

you explained why... incorrectly

Nicole Mazzuca (Nov 04 2018 at 16:08, on Zulip):

OCaml and Haskell have no need for places

Nicole Mazzuca (Nov 04 2018 at 16:08, on Zulip):

therefore, all of their expressions result in values

RalfJ (Nov 04 2018 at 16:08, on Zulip):

OCaml and Haskell have no need for places

at least we agree on that now, you said sth else above

Nicole Mazzuca (Nov 04 2018 at 16:09, on Zulip):

since Rust adds a kind of thing that an expression returns, you need the distinction between expressions that return values, and expressions that return places

RalfJ (Nov 04 2018 at 16:09, on Zulip):

therefore, all of their expressions result in values

they only have one kind of expression, and hence one kind of value

RalfJ (Nov 04 2018 at 16:09, on Zulip):

Rust, C, C++ have multiple kinds of expressions

RalfJ (Nov 04 2018 at 16:09, on Zulip):

and hence multiple kinds of values

Nicole Mazzuca (Nov 04 2018 at 16:09, on Zulip):

yes

Nicole Mazzuca (Nov 04 2018 at 16:09, on Zulip):

this is why it's called prvalue and glvalue in C++

RalfJ (Nov 04 2018 at 16:09, on Zulip):

"value" comes from "evaluate", its literally the result of evaluating something

RalfJ (Nov 04 2018 at 16:09, on Zulip):

so "places" evaluate to one kind of value, and 3+4 evaluates to another kind of value

Nicole Mazzuca (Nov 04 2018 at 16:10, on Zulip):

no?

Nicole Mazzuca (Nov 04 2018 at 16:10, on Zulip):

that's not how etymology works

RalfJ (Nov 04 2018 at 16:10, on Zulip):

lol its not how you define these terms, but its how an entire community does

RalfJ (Nov 04 2018 at 16:10, on Zulip):

you cannot just "no" that away

Nicole Mazzuca (Nov 04 2018 at 16:11, on Zulip):

no I mean literally, value does not come from evaluate

RalfJ (Nov 04 2018 at 16:11, on Zulip):

so do we agree there are two axis here? the place vs {"object"/"value"/3+4} axis, and the expression vs {value/result/evaluated term} axis.

Nicole Mazzuca (Nov 04 2018 at 16:11, on Zulip):

evaluate comes from value

Nicole Mazzuca (Nov 04 2018 at 16:12, on Zulip):

I don't agree - the latter is not an axis

RalfJ (Nov 04 2018 at 16:12, on Zulip):

what else is it...?

RalfJ (Nov 04 2018 at 16:13, on Zulip):

these two axis form 4 concepts, and all of these 4 concepts exist as types in rustc

RalfJ (Nov 04 2018 at 16:13, on Zulip):

there's nothing hypothetical about this

Nicole Mazzuca (Nov 04 2018 at 16:13, on Zulip):

you can have a concept which is not an axis

RalfJ (Nov 04 2018 at 16:13, on Zulip):

it seems to me you want to conflate the two kinds of values we have, but I disagree with mixing up distinct concepts

Nicole Mazzuca (Nov 04 2018 at 16:14, on Zulip):

hey, do you mind not being confrontational about this?

Nicole Mazzuca (Nov 04 2018 at 16:14, on Zulip):

you're putting words in my mouth.

Nicole Mazzuca (Nov 04 2018 at 16:14, on Zulip):

stop it. let me write the code

RalfJ (Nov 04 2018 at 16:15, on Zulip):

well TBH I think I'll reboot and do some gaming now. maybe we better have this discussion asychronously.

Nicole Mazzuca (Nov 04 2018 at 16:15, on Zulip):

god, you're really difficult to talk to, you know that?

RalfJ (Nov 04 2018 at 16:16, on Zulip):

well at least there's two of us that feel that way then

Nicole Mazzuca (Nov 04 2018 at 16:22, on Zulip):

see, as I'm thinking through this, I'm starting to agree that "value" meaning "the result of an expression" seems like a reasonable way to call these things

Nicole Mazzuca (Nov 04 2018 at 16:23, on Zulip):

"place" is good for "lvalue", but I'm not sure what we should call "values".

Nicole Mazzuca (Nov 04 2018 at 16:24, on Zulip):

"object" isn't good, it's overloaded

Nicole Mazzuca (Nov 05 2018 at 05:07, on Zulip):

apparently, compcert calls the type of r-values val

Nicole Mazzuca (Nov 05 2018 at 05:09, on Zulip):

ooh, thought: "immediate"

RalfJ (Nov 05 2018 at 12:30, on Zulip):

I was afraid "object" would be confusing for C/C++ people, which is why I specifically asked for your feedback.
I do see the clash with C++; I still do not understand though why you say this is not compatible with how C uses the term. They speak about "array objects" and such thing, all that seems perfectly consistent with how I proposed to use the term.

RalfJ (Nov 05 2018 at 12:30, on Zulip):

I am going to call them "robjects" for now just so that I can consistently refer to them some way; that term should be sufficiently bad that nobody should like it enough to grow attached to it. ;)

RalfJ (Nov 05 2018 at 12:31, on Zulip):

"immediate" is what I would call "things we can immediately manipulate" (miri literally has a type with that name, and it used to be called Value and the docs didn't get updated entirely oops). 3 is an intermediate, but (3, 3, 3) is not because it only exists in memory, doesn't fit in a register. (We also have two-register immediates, matching LLVM's ScalarPair, but that's where it ends.)
These are of course implementation details, but it is no good if we cannot use consistent terminology in rustc and miri.

RalfJ (Nov 05 2018 at 12:31, on Zulip):

the way I see it, immediates are a subclass of robjects

gnzlbg (Nov 05 2018 at 13:55, on Zulip):

it might be worth it to collect discussion points for this before the next meeting

gnzlbg (Nov 12 2018 at 11:19, on Zulip):

So I think I prefer the operand version

gnzlbg (Nov 12 2018 at 11:20, on Zulip):

I find using value that way a bit weird TBH, and I attach a kind of "temporary" meaning to the word operand that value does not seem to have. Although I agree with ubsan that the term is also overloaded when considering function operands.

nikomatsakis (Nov 13 2018 at 14:04, on Zulip):

@RalfJ I don't know that I understand what you were using "objects" to mean

nikomatsakis (Nov 13 2018 at 14:05, on Zulip):

were you saying that "object" referred to the expression 3+4, or is it some kind of runtime notion?

nikomatsakis (Nov 13 2018 at 14:08, on Zulip):

If so, that seems quite divergent from how I understand the term in C -- though fwiw I agree with @Nicole Mazzuca that it's not a great choice regardless. (I quite like value/place, and I confess I don't know why "value expression" seems like nonsense to you -- I understand that as "an expression that evaluates to a value", vs "place expression", which would be an expression that evaluates to a place (which can then be converted into a value).)

RalfJ (Nov 13 2018 at 14:08, on Zulip):

@nikomatsakis Both. That place vs. non-place is an axis orthogonal to expression vs. run-time.

RalfJ (Nov 13 2018 at 14:10, on Zulip):

"expression that evaluates to a value" is like... "wet water" or so. (dang the usual example that we use for that in German doesn't work.) It's a tautology.

nikomatsakis (Nov 13 2018 at 14:10, on Zulip):

well, it is in a language that lacks &

RalfJ (Nov 13 2018 at 14:10, on Zulip):

it doesnt make any additional distinction, at least not if "value" means that it does for me and anyone around me

RalfJ (Nov 13 2018 at 14:10, on Zulip):

no, this has nothing to do with places or not

nikomatsakis (Nov 13 2018 at 14:11, on Zulip):

but ok so we're trying to find some terminology that is distinct from both camps, and yet familiar to both?

RalfJ (Nov 13 2018 at 14:11, on Zulip):

"being a value" just means "being in some kind of normal-form"

nikomatsakis (Nov 13 2018 at 14:11, on Zulip):

do we consider **x an expression?

RalfJ (Nov 13 2018 at 14:11, on Zulip):

sure? was that ever a question?^^

nikomatsakis (Nov 13 2018 at 14:11, on Zulip):

that is, the way I think of it, it 'evaluates' to a place, which does involve some work

nikomatsakis (Nov 13 2018 at 14:12, on Zulip):

sure? was that ever a question?^^

not to me :) but I'm trying to understand the countours here :)

RalfJ (Nov 13 2018 at 14:12, on Zulip):

I see it as being an expression. but we have mutliple kinds of expressions. so "place expression" is a way to disambiguate those kinds.

nikomatsakis (Nov 13 2018 at 14:12, on Zulip):

and "value expression" doesn't work for you in this sense, because value is just an expression in a normal form?

nikomatsakis (Nov 13 2018 at 14:12, on Zulip):

I guess the question is whether one considers place a value

RalfJ (Nov 13 2018 at 14:12, on Zulip):

and then it evaluates, and if we want to fully precise we can say it evaluates to a "place value", but we can also just say it evaluates to a "place" because the fact that it is a value that we get is clear from context

RalfJ (Nov 13 2018 at 14:13, on Zulip):

if you only call the result of these computations a place, rustc::mir::Place would be misnamed

RalfJ (Nov 13 2018 at 14:13, on Zulip):

and "value expression" doesn't work for you in this sense, because value is just an expression in a normal form?

yes

nikomatsakis (Nov 13 2018 at 14:13, on Zulip):

sure, I think of that as representing a "place expression"

nikomatsakis (Nov 13 2018 at 14:13, on Zulip):

we don't have runtime values in that context

nikomatsakis (Nov 13 2018 at 14:13, on Zulip):

so there isn't much point to distinguish

nikomatsakis (Nov 13 2018 at 14:14, on Zulip):

in miri, it's different

RalfJ (Nov 13 2018 at 14:14, on Zulip):

I guess the question is whether one considers place a value

Right, that's why both $NON_PLACE and $EVAL_RESULT are still free variables in this discussion

nikomatsakis (Nov 13 2018 at 14:14, on Zulip):

ok, I am at least understanding better the crux of the conflict :)

RalfJ (Nov 13 2018 at 14:14, on Zulip):

we don't have runtime values in that context

The runtime version is rustc_mir::interpret::Place. They live happily next to each other. ;)

RalfJ (Nov 13 2018 at 14:15, on Zulip):

But the point I was just trying to make is that "place" in its own doesnt say if we are talking about a static/syntactic or a run-time concept

RalfJ (Nov 13 2018 at 14:15, on Zulip):

it is rather making a distinction along another axis, the place-$NON_PLACE axis

nikomatsakis (Nov 13 2018 at 14:16, on Zulip):

yes, ok

nikomatsakis (Nov 13 2018 at 14:16, on Zulip):

so expression/value is a potential thing for static/dynamic context

nikomatsakis (Nov 13 2018 at 14:16, on Zulip):

I think this is your preference, right?

RalfJ (Nov 13 2018 at 14:16, on Zulip):

and then we might have to disambugate by saying "place expression" (aka rustc::mir::Place) and "place $EVAL_RESULT" (aka rustc_mir::interpret::Place)

nikomatsakis (Nov 13 2018 at 14:17, on Zulip):

yes, ok, I see

nikomatsakis (Nov 13 2018 at 14:17, on Zulip):

/me shrugs

nikomatsakis (Nov 13 2018 at 14:17, on Zulip):

interesting question :)

RalfJ (Nov 13 2018 at 14:17, on Zulip):

and I prefer EVAL_RESULT=value, yes. And I think that is actually consistent with C, C just doesn't have a term for the static thing. But if it is too confusing we might better pick an altogether different word.

RalfJ (Nov 13 2018 at 14:17, on Zulip):

However, the bigger contention is around what to use for $NON_PLACE

nikomatsakis (Nov 13 2018 at 14:17, on Zulip):

I don't think value is a terrible word

nikomatsakis (Nov 13 2018 at 14:18, on Zulip):

right, the real question is the non-place part

RalfJ (Nov 13 2018 at 14:18, on Zulip):

I think "value" is a terrible choice for $NON_PLACE because there are many people that will think it means $EVAL_RESULT

nikomatsakis (Nov 13 2018 at 14:18, on Zulip):

yes, sorry, I meant that value is reasonable for $EVAL_RESULT

nikomatsakis (Nov 13 2018 at 14:19, on Zulip):

though it does leave open the question of what to call $NON_PLACE

nikomatsakis (Nov 13 2018 at 14:20, on Zulip):

I think part of this is that I've usually had a "subset" notion in my head

nikomatsakis (Nov 13 2018 at 14:20, on Zulip):

that is, you have "expressions" and "place expressions" (a subset of expressions that can be evaluated to a place)

nikomatsakis (Nov 13 2018 at 14:20, on Zulip):

similarly "values" and "place values" (aka pointers, though I think maybe they carry a bit more, like a type)

nikomatsakis (Nov 13 2018 at 14:20, on Zulip):

(just trying to think about why I never felt a lot of conflict here)

nikomatsakis (Nov 13 2018 at 14:21, on Zulip):

but it seems useful to consider them as disjoint sets -- sub isn't really right, since e.g. & treats them very differently

nikomatsakis (Nov 13 2018 at 14:21, on Zulip):

so they are not "subtypes" in the Liskov substitution sense

nikomatsakis (Nov 13 2018 at 14:21, on Zulip):

well, I guess it's more than "non-place expressions" get "promoted" to a place expression by creating a temporary

nikomatsakis (Nov 13 2018 at 14:22, on Zulip):

anyway... now I see why "immediate" was suggested. It makes sense, though it does carry this notion of "constant" -- everything you need to know is "immediately" available

nikomatsakis (Nov 13 2018 at 14:22, on Zulip):

it feels like the distinction between 3+4 and x is that the former "produces" a new value, I wonder if there is some name along those lines

nikomatsakis (Nov 13 2018 at 14:22, on Zulip):

/me will ponder

RalfJ (Nov 13 2018 at 14:23, on Zulip):

but it seems useful to consider them as disjoint sets -- sub isn't really right, since e.g. & treats them very differently

Indeed a place carries information that is not in a reference value: It carries an alignment. So I do not think subsets work.

Last update: Nov 19 2019 at 18:20UTC