Expression editing #1003
Expression editing #1003
Conversation
| sub-expressions, called the *operands* of the expression. The meaning of each | ||
| kind of expression dictates several things: | ||
| Expressions are the fundamental unit of computation. | ||
| When evaluated, they may have *effects* and evaluates to either a value or place. |
There was a problem hiding this comment.
I think we should probably keep the (otherwise known as "side effects") part
|
|
||
| The precedence of operators and expressions is ordered as follows, going from strongest to weakest. | ||
| Binary Operators at the same precedence level are grouped in the order given by their associativity. | ||
| Expressions in this table cannot have operands that are expressions lower in the table. |
There was a problem hiding this comment.
maybe say something here about how you can have operands that are lower precedence if wrapped in parenthesis or similar -- we don't want to imply it's impossible to write (a + b) * c after all
There was a problem hiding this comment.
I have that as a note after the table. I could put it before the table.
There was a problem hiding this comment.
I could also put a * (b + c) in the example as well.
| For example, `a * b + c` is actually parsed as an addition operator expression with the multiplication operator expression as its left operand. | ||
| The grammar, taking precedence into account, is too unweildy to read and understand. | ||
|
|
||
| The precedence of operators and expressions is ordered as follows, going from strongest to weakest. |
There was a problem hiding this comment.
| The precedence of operators and expressions is ordered as follows, going from strongest to weakest. | |
| The precedence of operators and expressions is ordered, from strongest to weakest, in the following table. |
Co-authored-by: Jacob Lifshay <[email protected]>
| Expressions are the fundamental unit of computation. | ||
| When evaluated, they may have *effects* and evaluates to either a value or place. | ||
|
|
||
| Where expressions are allowed are *expression contexts*. |
There was a problem hiding this comment.
This sentence sounds rather awkward. What is it you are trying to say? E.g.
"The syntactic positions that permit expressions to be written are called 'expression contexts'."
|
|
||
| * Whether or not to evaluate the operands when evaluating the expression | ||
| * The order in which to evaluate the operands | ||
| * How to combine the operands' values to obtain the value of the expression | ||
| * How to combine the operands' values to obtain the value or place of the expression |
There was a problem hiding this comment.
| * How to combine the operands' values to obtain the value or place of the expression | |
| * How to combine the operands' values or places to obtain the value or place of the expression |
Expressions like place.field have operands that are places, so I think if we want to be consistent we need to repeat this 'or place'.
Or we could find some term for "the result of evalauting an expression", i.e., a term for "value or place". Usually that term is "value" but we already burned that. In the Stacked Borrows paper formalization, we hence used the term "result".
| in the order given by their associativity. | ||
| The grammar for expressions as presented in this book is wrong. | ||
| It purposefully ignores that certain operands cannot be certain expressions due to precedence. | ||
| For example, `a * b + c` is actually parsed as an addition operator expression with the multiplication operator expression as its left operand. |
There was a problem hiding this comment.
| For example, `a * b + c` is actually parsed as an addition operator expression with the multiplication operator expression as its left operand. | |
| For example, `a * b + c` is actually parsed as an addition operator expression with the multiplication operator expression as its left operand (like `(a * b) + c`). |
| [field] references (`expr.f`) and parenthesized place expressions. All other | ||
| expressions are value expressions. | ||
| Expressions and expression contexts are divided into two *expression categories*: *place* and *value*. | ||
| For expressions, what they evaluate into determines their categories. |
There was a problem hiding this comment.
This feels awkward. We already established the "place or value" dichotomy earlier, so IMO it'd be better to say upfront (L45) that there are "place expressions" and "value expressions" -- or we find some way to not make the place/value distinction at all until here.
There was a problem hiding this comment.
My thought was that L45 gives a summary, and then this section expands upon the idea. It would feel weird to not include the dichotomy in the main definition but including the terms in the main definition would be more detail then necessary.
Also, the fact that the category exists for both the expression and the expression context makes this harder to describe.
There was a problem hiding this comment.
Also, the fact that the category exists for both the expression and the expression context makes this harder to describe.
These are not two independent facts, so maybe there is a way to present them as one fact? There are two kinds of expressions, basically two kinds of "non-terminals" in the grammar (ValExpr, PlaceExpr), so naturally there are two questions: which class does eache xpression fall in, and which Expr in the grammar is refined to each of these two non-terminals?
| Expressions and expression contexts are divided into two *expression categories*: *place* and *value*. | ||
| For expressions, what they evaluate into determines their categories. | ||
| Expressions that evaluate to a value are *value expressions* while those that evaluate to a place are *place expressions*. | ||
| For expression contexts, whether they operate on a place or value determines their context. |
There was a problem hiding this comment.
I have no idea what this last sentence is supposed to tell me.
There was a problem hiding this comment.
Hmm, I'll think of a way to phrase it better.
|
|
||
| A *value expression* is an expression that represents an actual value. | ||
| Evaluating an expression in the opposite expression context has effects after evaluation of the expression to produce the expected place or value of the context. |
There was a problem hiding this comment.
I only understood this sentence after reading the rest of this paragraph. What about something more like "When a place expression is evaluated in value context or vice versa, extra effects apply to perform the required conversion"?
|
|
||
| * The left operand of an [assignment][assign] or [compound assignment] | ||
| expression. | ||
| * [Paths] which refer to local variables or [static variables]. |
There was a problem hiding this comment.
Aren't all paths place expressions?
This sounds like only some paths are place expressions.
There was a problem hiding this comment.
I actually don't know. This was here beforehand.
There was a problem hiding this comment.
Maybe this was meant as "Paths, which refer to ...". IOW, this is a definition of "Paths".
| * [Array indexing expressions] | ||
| * [Parenthetical expressions][paren] when its enclosed operand is a place expression | ||
|
|
||
| The following list all place expression contexts. |
There was a problem hiding this comment.
| The following list all place expression contexts. | |
| The following lists all place expression contexts. |
| All other contexts are value expression contexts. | ||
|
|
||
| * The initializer of a [let statement]. | ||
| * The assigned place operand of an [assignment][assign] or [compound assignment] expression. | ||
| * The operand of a unary [borrow] or [dereference][deref] operator. |
There was a problem hiding this comment.
Should "address-of operator" be listed here?
There was a problem hiding this comment.
That's in your PR which I need to get back to. But my work schedule this week is night/morning/night/morning and I had a migraine over my weekend. I'll rebase against master once that one is merged.
There was a problem hiding this comment.
No worries, get a good cup of sleep first. :)
| * The operand of a unary [borrow] or [dereference][deref] operator. | ||
| * The operand of a field expression. | ||
| * The container operand of a field expression. |
There was a problem hiding this comment.
It's the operand of the field expression, given a name. See the field expression page, which I should add a link to on this list.
There was a problem hiding this comment.
That name strikes me as rather counterintuitive. Maybe "base" would be better?
Since there is only one operand, just saying "the operand" would also work IMO.
|
☔ The latest upstream changes (possibly bf115a4) made this pull request unmergeable. Please resolve the merge conflicts. |
rustbot
added
the
S-waiting-on-author
Fixes #972
There's more that I want to do, but I think it requires creating a brand new chapter for places. Main information on temporaries don't really belong in the expressions chapter, nor does the definition of moving and copying.