tweaks

Author: RalfJung

wip/memory-interface.md

@@ -4,8 +4,8 @@
 
 The purpose of this document is to describe the interface between a Rust program and memory.
 This interface is a key part of the Rust Abstract Machine: it lets us separate concerns by splitting the Machine (i.e., its specification) into two pieces, connected by this well-defined interface:
-* The *expression/statement semantics* of Rust boils down to explaining which "memroy events" (calls to the memory interface) happen in which order. This part of the specification is *pure* in the sense that it has no "state": everything that needs to be remembered from one expression evaluation to the next is communicated through memory.
-* The Rust *memory model* explains which interactions with the memory are legal (the others are UB), and which values can be returned by reads.
+* The *expression/statement semantics* of Rust boils down to explaining which "memroy events" (calls to the memory interface) happen in which order - expressed as calls to the methods of this interface, and reactions to its return values. This part of the specification is *pure* in the sense that it has no "state": everything that needs to be remembered from one expression evaluation to the next is communicated through memory.
+* The Rust *memory model* explains which interactions with the memory are legal (the others are UB), and which values can be returned by reads. A memory model is defined by implementing the memory interface.
 
 The interface shown below is also opinionated in several ways.
 It is not intended to be able to support *any imaginable* memory model, but rather start the process of reducing the design space of what we consider a "reasonable" memory model for Rust.
@@ -20,6 +20,9 @@ One key question a memory model has to answer is *what is a pointer*.
 It might seem like the answer is just "an integer of appropriate size", but [that is not the case][pointers-complicated].
 This becomes even more prominent with aliasing models such as [Stacked Borrows].
 So the interface will leave it up to the concrete instance to answer this question, and carry `Pointer` as an associated type.
+Practically speaking, `Pointer` will be some representation of an "address", plus [provenance] information.
+
+[provenance]: https://github.com/rust-lang/unsafe-code-guidelines/blob/master/reference/src/glossary.md#pointer-provenance
 
 ## Bytes