Grammatical Tweaks to the Docs (FuelLabs#602)

* Grammatical Changes to Docs

* concatenate

Co-authored-by: John Adler <[email protected]>

* add hyphen

Co-authored-by: John Adler <[email protected]>

* Update docs/src/sway-on-chain/smart_contracts.md

Co-authored-by: John Adler <[email protected]>

Co-authored-by: John Adler <[email protected]>

docs/src/advanced/assembly.md

@@ -29,7 +29,7 @@ Note that in the above example:
 - we declared a second register `r2` (you may choose any register names you want).
 - we use the `add` opcode to add `one` to the value of `r1` and store it in `r2`.
 - `one` is an example of a "reserved register", of which there are 16 in total. Further reading on this is linked below under "Semantics".
-- we return `r2` & specify the return-type as being u32 (the return type is u64 by default).
+- we return `r2` & specify the return type as being u32 (the return type is u64 by default).
 
 ## Helpful Links
 

docs/src/advanced/generic_types.md

@@ -2,7 +2,7 @@
 
 ## Basics
 
-In Sway, generic types follow a very similar pattern to those in Rust. Let's look as some example syntax, 
+In Sway, generic types follow a very similar pattern to those in Rust. Let's look at some example syntax,
 starting with a generic function:
 
 ```sway
@@ -11,14 +11,14 @@ fn noop<T>(argument: T) -> T {
 }
 ```
 
-Here, the `noop()` function trivially returns exactly what was given to it. `T` is a _type parameter_, and it saying
+Here, the `noop()` function trivially returns exactly what was given to it. `T` is a _type parameter_, and it says
 that this function exists for all types T. More formally, this function could be typed as:
 
 ```math
 noop :: ∀T. T -> T
 ```
 
-Generic types are a way to refer to types _in general_, meaning without specifying a single type. Clearly, our `noop` function
+Generic types are a way to refer to types _in general_, meaning without specifying a single type. Our `noop` function
 would work with any type in the language, so we don't need to specify `noop(argument: u8) -> u8`, `noop(argument: u16) -> u16`, etc.
 
 ## Code Generation
@@ -30,7 +30,7 @@ purely shorthand for the sake of ergonomics.
 
 ## Trait Constraints
 
-Of course, our `noop()` function is not useful. Often, a programmer will want to declare functions over a types which satisfy certain traits.
+Of course, our `noop()` function is not useful. Often, a programmer will want to declare functions over types which satisfy certain traits.
 For example, let's try to implement the successor function, `successor()`, for all numeric types.
 
 ```sway
@@ -45,7 +45,7 @@ Run `forc build`, and you will get:
 
 ```sway
 .. |
- 9 |   where T: Add 
+ 9 |   where T: Add
 10 |   {
 11 |     argument + 1                                        
    |                ^ Mismatched types: expected type "T" but saw type "u64"
@@ -102,7 +102,7 @@ Both generic enums and generic structs can be trait constrained, as well. Consid
 
 ```sway
 struct Foo<T>
-  where T: Add 
+  where T: Add
 {
     field_one: T
 }

docs/src/advanced/traits.md

@@ -16,7 +16,7 @@ trait Compare {
 }
 ```
 
-We have just declared a trait called `Compare`. After the name of the trait, there are two _blocks_ of code (a _block_ is code enclosed in `{` curly brackets `}`). The first block is the _interface surface_. The second block are the _methods_ provided by the trait. If a type is able to provide the methods in the interface surface, then it gets access to the methods in the trait for free! What the above trait is saying is: if you can determine if two values are equal, then for free, you can determine that they are not equal. Note that trait methods have access to the methods defined in the interface surface.
+We have just declared a trait called `Compare`. After the name of the trait, there are two _blocks_ of code (a _block_ is code enclosed in `{` curly brackets `}`). The first block is the _interface surface_. The second block is the _methods_ provided by the trait. If a type can provide the methods in the interface surface, then it gets access to the methods in the trait for free! What the above trait is saying is: if you can determine if two values are equal, then for free, you can determine that they are not equal. Note that trait methods have access to the methods defined in the interface surface.
 
 ## Implementing a Trait
 
@@ -39,7 +39,7 @@ The above snippet declares all of the methods in the trait `Compare` for the typ
 Often, libraries and APIs have interfaces that are abstracted over a type that implements a certain trait. It is up to the consumer of the interface to implement that trait for the type they wish to use with the interface. For example, let's take a look at a trait and an interface built off of it.
 
 ```sway
-library games; 
+library games;
 
 pub enum Suit {
     Hearts: (),
@@ -59,7 +59,7 @@ fn play_game_with_deck<T>(a: Vec<T>) where T: Card {
 ```
 
 
-Now, if you want to use the function `play_game_with_deck` with your own personal struct, you must implement `Card` for your struct. Note that the following code example assumes a dependency _games_ has been included in the `Forc.toml` file.
+Now, if you want to use the function `play_game_with_deck` with your struct, you must implement `Card` for your struct. Note that the following code example assumes a dependency _games_ has been included in the `Forc.toml` file.
 
 ```sway
 script;
@@ -92,4 +92,3 @@ fn random_suit(i: u64) -> Suit {
   [ ... ]
 }
 ```
-

docs/src/basics/built_in_types.md

@@ -1,8 +1,8 @@
 # Built-in Types
 
-Every value in Sway is of a certain type. Although, deep down, all values are just ones and zeroes in silicon, Sway needs to know what those ones and zeroes actually mean. This is accomplished with _types_.
+Every value in Sway is of a certain type. Although deep down, all values are just ones and zeroes in silicon, Sway needs to know what those ones and zeroes actually mean. This is accomplished with _types_.
 
-Sway is a statically typed language. At compile time, the types of every value must be known. This does not mean you need to specify every single type: usually the type can be reasonably inferred.
+Sway is a statically typed language. At compile time, the types of every value must be known. This does not mean you need to specify every single type: usually, the type can be reasonably inferred.
 
 ## Primitive Types
 
@@ -16,13 +16,13 @@ Sway has the following primitive types:
 1. `bool` (Boolean `true` or `false`)
 1. `b256` (256 bits (32 bytes), i.e. a hash)
 
-All other types in Sway are built up of these primitive types, or references to these primitive types. You may notice that there are no signed integers—this is by design. In the blockchain domain that Sway occupies, floating point values and negative numbers have smaller utility, so their implementation has been left up to libraries for specific use cases.
+All other types in Sway are built up of these primitive types, or references to these primitive types. You may notice that there are no signed integers—this is by design. In the blockchain domain that Sway occupies, floating-point values and negative numbers have smaller utility, so their implementation has been left up to libraries for specific use cases.
 
 ## Numeric Types
 
 All of the unsigned integer types are numeric types, and the `byte` type can also be viewed as an 8-bit unsigned integer.
 
-Numbers can be declared with binary syntax, hexadecimal syntax, base-10 syntax, and with underscores for delineation. Let's take a look at the following valid numeric primitives:
+Numbers can be declared with binary syntax, hexadecimal syntax, base-10 syntax, and underscores for delineation. Let's take a look at the following valid numeric primitives:
 
 ```sway
 0xffffff    // hexadecimal
@@ -48,7 +48,7 @@ fn returns_false() -> bool {
 
 ## String Type
 
-In Sway, static-length strings are a primitive type. This means that when you declare a string, its size is a part of its type. This is necessary for the compiler to know how much memory to give for storage of that data. The size of the string is denoted with square brackets. Let's take a look:
+In Sway, static-length strings are a primitive type. This means that when you declare a string, its size is a part of its type. This is necessary for the compiler to know how much memory to give for the storage of that data. The size of the string is denoted with square brackets. Let's take a look:
 
 ```sway
 let my_string: str[4] = "fuel";
@@ -58,13 +58,13 @@ Because the string literal `"fuel"` is four letters, the type is `str[4]`, denot
 
 ## Compound Types
 
-_Compound types_ are types which group multiple values into one type. In Sway, we have arrays and tuples.
+_Compound types_ are types that group multiple values into one type. In Sway, we have arrays and tuples.
 
 ## Tuple Types
 
 _note: tuples are a work in progress and are tracked by [this PR](https://github.com/FuelLabs/sway/pull/399)_
 
-A tuple is a general-purpose static-length aggregation of types. In more plain terms, a tuple is a single type which consists of an aggregate of zero or more types. The internal types that make up a tuple, and the tuple's cardinality, define the tuple's type. Let's take a look at some examples.
+A tuple is a general-purpose static-length aggregation of types. In more plain terms, a tuple is a single type that consists of an aggregate of zero or more types. The internal types that make up a tuple, and the tuple's cardinality, define the tuple's type. Let's take a look at some examples.
 
 ```sway
 let x: (u64, u64) = (0, 0);

docs/src/basics/custom_types.md

@@ -43,7 +43,7 @@ Structs have zero memory overhead. What that means is that in memory, each struc
 
 ## Enums
 
-_Enumerations_, or _enums_, are also known as _sum types_. An enum is a type which could be one of a number of variants. To declare an enum, you enumerate all potential variants. Let's look at _enum declaration syntax_:
+_Enumerations_, or _enums_, are also known as _sum types_. An enum is a type that could be one of several variants. To declare an enum, you enumerate all potential variants. Let's look at _enum declaration syntax_:
 
 ```sway
 enum Color {
@@ -55,7 +55,7 @@ enum Color {
 }
 ```
 
-Here, we have defined five potential colors. Each individual enum variant is just the color name. As there is no extra data associated with each variant, we say that each variant is of type `()`, or unit. It is also possible to have an enum variant contain extra data. Take a look at this more substantial example, which combines struct declarations with enum variants:
+Here, we have defined five potential colors. Each enum variant is just the color name. As there is no extra data associated with each variant, we say that each variant is of type `()`, or unit. It is also possible to have an enum variant contain extra data. Take a look at this more substantial example, which combines struct declarations with enum variants:
 
 ```sway
 use std::collections::Vec;
@@ -119,14 +119,14 @@ let event = InventoryEvent::ItemLoss(Claim {
 
 _This information is not vital if you are new to the language, or programming in general._
 
-Enums do have some memory overhead. In order to know which variant is being represented, Sway stores a one-word (8-byte) tag for the enum variant. The space reserved after the tag is equivalent to the size of the _largest_ enum variant. So, to calculate the size of an enum in memory, add 8 bytes to the size of the largest variant. For example, in the case of `Color` above, where the variants are all `()`, the size would be 8 bytes since the size of the largest variant is 0 bytes.
+Enums do have some memory overhead. To know which variant is being represented, Sway stores a one-word (8-byte) tag for the enum variant. The space reserved after the tag is equivalent to the size of the _largest_ enum variant. So, to calculate the size of an enum in memory, add 8 bytes to the size of the largest variant. For example, in the case of `Color` above, where the variants are all `()`, the size would be 8 bytes since the size of the largest variant is 0 bytes.
 
 ## Methods and Associated Functions
 
-_Methods_ are functions which are associated with a specific type and either refer to that type or mutate it. _Associated functions_ are very similar, but they do not actually use any of the data in the type. Associated functions could be standalone functions, but they
+_Methods_ are functions that are associated with a specific type and either refer to that type or mutate it. _Associated functions_ are very similar, but they do not use any of the data in the type. Associated functions could be standalone functions, but they
 are included in a specific type for organizational or semantic reasons.
 
-In order to declare methods and associated functions for a struct or enum, use an _impl block_. Here, `impl` stands for implementation.
+To declare methods and associated functions for a struct or enum, use an _impl block_. Here, `impl` stands for implementation.
 
 ```sway
 script;

docs/src/basics/reference_types.md

@@ -2,9 +2,9 @@
 
 If you have familiarity with references, also called pointers, from other languages, Sway references are no different. If you're new to this concept, this chapter is for you!
 
-Memory in a computer is held in RAM. When you buy a Macbook Pro 16GB, for example, that 16GB number is referring to the _memory_, or _RAM_, available. In the FuelVM, we also have memory. When you instantiate a variable in a Sway program, it is written to some spot in memory. We need to keep track of _where_ exactly that value was written in order to utilize it, though.
+Memory in a computer is held in RAM. When you buy a Macbook Pro 16GB, for example, that 16GB number is referring to the _memory_, or _RAM_, available. In the FuelVM, we also have memory. When you instantiate a variable in a Sway program, it is written to some spot in memory. We need to keep track of _where_ exactly that value was written to utilize it, though.
 
-Every single byte in FuelVM memory has a name. The first byte's name is `0x01`. The second byte's name is `0x02`. The 54,321st byte's name is `0xD431`[^1]. A reference is a variable which contains the name of a specific location in the FuelVM's memory. This is useful if you want to reason about the memory which contains the value and not the value itself.
+Every single byte in FuelVM memory has a name. The first byte's name is `0x01`. The second byte's name is `0x02`. The 54,321st byte's name is `0xD431`[^1]. A reference is a variable that contains the name of a specific location in the FuelVM's memory. This is useful if you want to reason about the memory which contains the value and not the value itself.
 
 ```sway
 script;
@@ -14,12 +14,12 @@ fn main() {
 }
 ```
 
-[^1]: Check out [this article](https://en.wikipedia.org/wiki/Hexadecimal) if you're not used to seeing numbers with letters in them. 
+[^1]: Check out [this article](https://en.wikipedia.org/wiki/Hexadecimal) if you're not used to seeing numbers with letters in them.
 
 ## Dereferencing
 
 ## Storage References
 
 ## Implicit References
 
-Types larger than one word in size are implicitly reference types.
+Types larger than one word in size are implicitly reference types.

docs/src/basics/variables.md

@@ -1,6 +1,6 @@
 # Variables
 
-Variables in Sway are _immutable by default_. This means that, by default, once a variable is declared, its value cannot change. This is one of the ways in which Sway encourages safe programming, and many modern languages have this same default. Let's take a look at variables in detail.
+Variables in Sway are _immutable by default_. This means that, by default, once a variable is declared, its value cannot change. This is one of how Sway encourages safe programming, and many modern languages have this same default. Let's take a look at variables in detail.
 
 ## Declaring a Variable
 
@@ -25,7 +25,7 @@ let mut foo = 5;
 foo = 6;
 ```
 
-Now, `foo` is mutable, and the reassignment to the number `6` is valid. That is, we are allowed to _mutate_ the variable `foo` in order to change its value.
+Now, `foo` is mutable, and the reassignment to the number `6` is valid. That is, we are allowed to _mutate_ the variable `foo` to change its value.
 
 ## Type annotations
 

docs/src/blockchain-concepts/identifiers.md

@@ -5,4 +5,4 @@ Addresses in Sway are similar to Ethereum addresses. The two major differences a
 1. Sway addresses are 32 bytes long (instead of 20), and
 1. are computed with the SHA-256 hash of the public key instead of the keccak-256 hash.
 
-Contracts, on the other hand, are uniquely identified with a contract ID rather than an address. A contract's ID is also 32 bytes long, and is calculated [here](https://github.com/FuelLabs/fuel-specs/blob/master/specs/protocol/identifiers.md#contract-id).
+Contracts, on the other hand, are uniquely identified with a contract ID rather than an address. A contract's ID is also 32 bytes long and is calculated [here](https://github.com/FuelLabs/fuel-specs/blob/master/specs/protocol/identifiers.md#contract-id).

docs/src/blockchain-concepts/native_assets.md

@@ -4,6 +4,6 @@ The FuelVM has built-in support for working with multiple assets.
 
 What does this mean in practice?
 
-As in Ethereum, sending ETH to an address or contract is an operation built in to the FuelVM, meaning it doesn't rely on the existence of some token smart contract to update balances in order to track ownership.
+As in Ethereum, sending ETH to an address or contract is an operation built into the FuelVM, meaning it doesn't rely on the existence of some token smart contract to update balances to track ownership.
 
-However, unlike Ethereum, the process for sending _any_ native asset is the same. This means that while you would still need a smart contract to handle minting and burning of fungible tokens, the sending and receiving of these tokens can be done independently of the token contract.
+However, unlike Ethereum, the process for sending _any_ native asset is the same. This means that while you would still need a smart contract to handle the minting and burning of fungible tokens, the sending and receiving of these tokens can be done independently of the token contract.

docs/src/getting-started/sway-toolchain.md

@@ -8,7 +8,7 @@ The "Fuel Orchestrator" Forc is our equivalent of Rust's [Cargo](https://doc.rus
 
 ### Sway Language Server (`forc lsp`)
 
-The Sway Language Server `forc lsp` is provided to expose features to IDEs. Currently, only [Visual Studio Code is supported through a plugin](https://marketplace.visualstudio.com/items?itemName=FuelLabs.sway-vscode-plugin). Vim support is forthcoming, though [syntax highlighting is provided](https://github.com/FuelLabs/sway.vim). Note that there is no need to manually run `forc lsp` (the plugin will automaticaly start it), however it should be included in your `$PATH` if you are building `forc` from source.
+The Sway Language Server `forc lsp` is provided to expose features to IDEs. Currently, only [Visual Studio Code is supported through a plugin](https://marketplace.visualstudio.com/items?itemName=FuelLabs.sway-vscode-plugin). Vim support is forthcoming, though [syntax highlighting is provided](https://github.com/FuelLabs/sway.vim). Note that there is no need to manually run `forc lsp` (the plugin will automatically start it), however, it should be included in your `$PATH` if you are building `forc` from source.
 
 ## Fuel Core (`fuel-core`)
 

docs/src/smart-contract-development/purity.md

@@ -1,6 +1,6 @@
 # Purity
 
-A function is _pure_ if it does not access any [persistent storage](./storage.md). Conversely, function is _impure_ if it does access any storage. Naturally, as storage is only available in smart contracts, impure functions cannot be used in predicates, scripts, or libraries. A pure function cannot call an impure function.
+A function is _pure_ if it does not access any [persistent storage](./storage.md). Conversely, the function is _impure_ if it does access any storage. Naturally, as storage is only available in smart contracts, impure functions cannot be used in predicates, scripts, or libraries. A pure function cannot call an impure function.
 
 Functions are pure by default but can be opted in to impurity via the `impure` keyword[^1]: