WIP: add hunspell to CI

Author: arvidn

.github/workflows/spelling.yml

@@ -0,0 +1,25 @@
+name: Spell checking
+
+on:
+  push:
+    branches:
+      - main
+    tags:
+        - '**'
+  pull_request:
+    branches:
+      - '**'
+
+jobs:
+  hunspell:
+    name: 
+    runs-on: ubuntu-latest
+
+    steps:
+    - name: install hunspell
+      run: sudo apt-get install hunspell
+
+    - name: run hunspell
+      run: |
+         cat hunspell/chialisp.dic hunspell/hex.dic hunspell/clvm-ops.dic >temp.dic
+         hunspell -d en_US -p temp.dic -l docs/*.md docs/ref/*.md

docs/basics.md

@@ -5,7 +5,7 @@ sidebar_label: 1 - CLVM Basics
 ---
 
 CLVM is the compiled, minimal version of ChiaLisp that is used by the Chia network.
-Chialisp compiles into CLVM so it's important to understand how it works.
+ChiaLisp compiles into CLVM so it's important to understand how it works.
 The full set of operators is documented [here](https://chialisp.com/docs/ref/clvm)
 
 This guide will cover the basics of the language and act as an introduction to the structure of programs.
@@ -73,7 +73,7 @@ For example, this program is just the value `100`:
 (q . 100)
 ```
 
-Note that in the higher level Chialisp language, values do not need to be quoted.
+Note that in the higher level ChiaLisp language, values do not need to be quoted.
 
 ## Lists and Programs
 
@@ -252,7 +252,7 @@ $ brun '(i (q . ()) (q . 70) (q . 80))'
 80
 ```
 
-Note that both `B` and `C` are evaluated eagerly, just like all subexpressions.
+Note that both `B` and `C` are evaluated eagerly, just like all sub-expressions.
 To defer evaluation until after the condition, `B` and `C` must be quoted (with
 `q`), and then evaluated with `(a)`.
 

docs/coin_lifecycle.md

@@ -7,7 +7,7 @@ You should now understand how to create Chialisp puzzles that lock up coins with
 
 ## The Coin Set Model
 
-Chia's model of how coins are stored is called the **coin set** model and is closely modelled after Bitcoin's UTXO model.  The idea is simple, every full node holds onto a database of **coin records**:
+Chia's model of how coins are stored is called the **coin set** model and is closely modeled after Bitcoin's UTXO model.  The idea is simple, every full node holds onto a database of **coin records**:
 
 ```
 class Coin:
@@ -117,4 +117,4 @@ Furthermore, generators also enable the compression of certain puzzles in a bloc
 
 You should now have a pretty decent grasp of the environment that your puzzles will be running in.  Writing secure Chialisp puzzles requires a somewhat unique way of looking at things that is not shared by many other programming languages or blockchains.  Understanding of the network is inextricably intertwined with the creation of puzzles and while that creates a steep learning curve, it also enables incredible functionality in an incredibly compact format.
 
-It is highly recommended that you fully understand this section before you decide to deploy any smart contract so that you can ensure they are secure and functional.  Simply running the puzzle on your computer is no substitute for having it run on millions of nodes with indeterminable intent.
+It is highly recommended that you fully understand this section before you decide to deploy any smart contract so that you can ensure they are secure and functional.  Simply running the puzzle on your computer is no substitute for having it run on millions of nodes with indeterminable intent.

docs/coins_spends_and_wallets.md

@@ -6,14 +6,14 @@ title: 2 - Coins, Spends and Wallets
 This guide directly continues on from [part 1](/docs/) so if you haven't read that, please do so before reading this.
 
 This section of the guide will cover evaluating a program inside a program, how ChiaLisp relates to transactions and coins on the Chia network, and cover some techniques to create smart transactions using ChiaLisp.
-If there are any terms that you aren't sure of, be sure to check the [glossary](/docs/glossary).
+If there are any terms that you are not sure of, be sure to check the [glossary](/docs/glossary).
 
 ## Coins
 
 A coin's ID is constructed from 3 pieces of information.
 
 1. The ID of its parent
-2. The hash of its puzzle (AKA the puzzlehash)
+2. The hash of its puzzle (AKA the puzzle hash)
 3. The amount that it is worth
 
 To construct a coin ID simply take the hash of these 3 pieces of information concatenated in order.
@@ -79,7 +79,7 @@ Here is the complete list of conditions along with their format and behaviour.
 
 * **AGG_SIG_UNSAFE - [49] - (49 pubkey message)**: This spend is only valid if the attached aggregated signature contains a signature from the given public key of the given message. This is labeled unsafe because if you sign a message once, any other coins you have that require that signature may potentially also be unlocked. It's probably better just to use AGG_SIG_ME because of the natural entropy introduced by the coin ID.
 * **AGG_SIG_ME - [50] - (50 pubkey message)**: This spend is only valid if the attached aggregated signature contains a signature from the specified public key of that message concatenated with the coin's ID.
-* **CREATE_COIN - [51] - (51 puzzlehash amount)**: If this spend is valid, then create a new coin with the given puzzlehash and amount.
+* **CREATE_COIN - [51] - (51 puzzlehash amount)**: If this spend is valid, then create a new coin with the given puzzle hash and amount.
 * **ASSERT_FEE - [52] - (52 amount)**: This spend is only valid if there is unused value in this transaction equal to *amount*, which is explicitly to be used as the fee.
 * **CREATE_COIN_ANNOUNCEMENT - [60] - (60 message)**: If this spend is valid, this creates an ephemeral announcement with an ID dependent on the coin that creates it. Other coins can then assert an announcement exists for inter-coin communication inside a block.
 * **ASSERT_COIN_ANNOUNCEMENT - [61] - (61 announcementID)**: This spend is only valid if there was an announcement in this block matching the announcementID.  The announcementID is the hash of the message that was announced concatenated with the coin ID of the coin that announced it `announcementID == sha256(coinID + message)`.
@@ -141,7 +141,7 @@ $ brun '(i (= (sha256 2) (q . 0x2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e
 There is one final change we need to make before this is a complete smart transaction.
 
 If you want to invalidate a spend then you need to raise an exception using `x`.
-Otherwise you just have a valid spend that isn't returning any conditions, and that would destroy our coin and not create a new one!
+Otherwise you just have a valid spend that is not returning any conditions, and that would destroy our coin and not create a new one!
 So we need to change the fail condition to be `(x "wrong password")` which means the transaction fails and the coin is not spent.
 
 If we're doing this then we should also change the `(i A B C)` pattern to `(a (i A (q . B) (q . C)) 1)`.
@@ -174,18 +174,18 @@ Suppose we lock a coin up using the following puzzle:
 (q . ((51 0x365bdd80582fcc2e4868076ab9f24b482a1f83f6d88fd795c362c43544380e7a 100)))
 ```
 
-Regardless of what solution is passed this puzzle will *always* return instructions to create a new coin with the puzzlehash 0x365bdd80582fcc2e4868076ab9f24b482a1f83f6d88fd795c362c43544380e7a and the amount 100.
+Regardless of what solution is passed this puzzle will *always* return instructions to create a new coin with the puzzle hash 0x365bdd80582fcc2e4868076ab9f24b482a1f83f6d88fd795c362c43544380e7a and the amount 100.
 
 ```lisp
 $ brun '(q . ((51 0x365bdd80582fcc2e4868076ab9f24b482a1f83f6d88fd795c362c43544380e7a 100)))' '(80 90 "hello")'
 ((51 0x365bdd80582fcc2e4868076ab9f24b482a1f83f6d88fd795c362c43544380e7a 100))
 
-$ brun '(q . ((51 0x365bdd80582fcc2e4868076ab9f24b482a1f83f6d88fd795c362c43544380e7a 100)))' '("it doesn't matter what we put here")'
+$ brun '(q . ((51 0x365bdd80582fcc2e4868076ab9f24b482a1f83f6d88fd795c362c43544380e7a 100)))' '("it does not matter what we put here")'
 ((51 0x365bdd80582fcc2e4868076ab9f24b482a1f83f6d88fd795c362c43544380e7a 100))
 ```
 
 In this example the result of spending the coin is entirely determined from the puzzle.
-Even though anybody could initiate the spend of the coin, the person that locked the coin up has all the power in the way that the coin is spent as the solution doesn't matter at all.
+Even though anybody could initiate the spend of the coin, the person that locked the coin up has all the power in the way that the coin is spent as the solution does not matter at all.
 
 Conversely lets consider a coin locked up with the following puzzle:
 
@@ -274,7 +274,7 @@ Change making is simple.
 If a wallet spends less than the total value of a coin, they can create another coin with the remaining portion of value, and lock it up with the standard puzzle for themselves again.
 You can split a coin up into as many new coins with fractions of the original value as you'd like.
 
-You cannot create two coins of the same value, with the same puzzlehash, from the same parent as this will lead to an ID collision and the spend will be rejected.
+You cannot create two coins of the same value, with the same puzzle hash, from the same parent as this will lead to an ID collision and the spend will be rejected.
 
 ### Coin Aggregation and Spend Bundles
 

docs/common_functions.md

@@ -1,6 +1,6 @@
 ---
 id: common_functions
-title: 5 - Common Functions in Chialisp
+title: 5 - Common Functions in ChiaLisp
 ---
 
 When you start to write full smart contracts, you will start to realize that you will need certain common functionality in a lot of puzzles.  Let's go over how to include them and what some of them are:
@@ -36,7 +36,7 @@ Also note that the include files are a special format. Everything that is define
 
 When puzzles are hashed, they are not simply serialized and passed to sha256.  Instead, we take the *tree hash* of the puzzle.
 
-Recall that every clvm program can be represented as a binary tree.  Every object is either an atom (a leaf of the tree) or a cons box (a branch of the tree).  When we hash the puzzle we start at the leaves of the tree and hash our way up, concatenating either a 1 or a 2 to denote that it's either an atom or a cons box.  Once a cons box is hashed, it becomes a new leaf to be hashed into its parent cons box and the process recurses.  Here's what that looks like in Chialisp:
+Recall that every clvm program can be represented as a binary tree.  Every object is either an atom (a leaf of the tree) or a cons box (a branch of the tree).  When we hash the puzzle we start at the leaves of the tree and hash our way up, concatenating either a 1 or a 2 to denote that it's either an atom or a cons box.  Once a cons box is hashed, it becomes a new leaf to be hashed into its parent cons box and the process recurses.  Here's what that looks like in ChiaLisp:
 
 ```lisp
 (defun sha256tree1
@@ -48,11 +48,11 @@ Recall that every clvm program can be represented as a binary tree.  Every objec
 )
 ```
 
-It is extremely useful to calculate tree hashes within a Chialisp puzzle.  You can assert puzzles of other coins, condense puzzles for easier signing, and make CREATE_COIN conditions that are dependent on some passed in data.  
+It is extremely useful to calculate tree hashes within a ChiaLisp puzzle.  You can assert puzzles of other coins, condense puzzles for easier signing, and make CREATE_COIN conditions that are dependent on some passed in data.  
 
 ## Currying
 
-Currying is an extremely important concept in Chialisp that is responsible for almost the entirety of how state is stored in coins.  The idea is to pass in arguments to a puzzle *before* it is hashed.  When you curry, you commit to solution values so that the individual solving the puzzle cannot change them.  Let's take a look at how this is implemented in Chialisp:
+Currying is an extremely important concept in ChiaLisp that is responsible for almost the entirety of how state is stored in coins.  The idea is to pass in arguments to a puzzle *before* it is hashed.  When you curry, you commit to solution values so that the individual solving the puzzle cannot change them.  Let's take a look at how this is implemented in ChiaLisp:
 
 ```lisp
 ;; utility function used by curry
@@ -82,7 +82,7 @@ You can also do the reverse operation.  Given a program, you can *uncurry* the l
 ; (c curry_arg_1 (c curry_arg_2 1))
 ```
 
-Let's take our password locked coin example from earlier, this time as a Chialisp puzzle:
+Let's take our password locked coin example from earlier, this time as a ChiaLisp puzzle:
 
 ```lisp
 (mod (password new_puzhash amount)
@@ -143,7 +143,7 @@ Note that this required that we run the currying module using `brun` in our own
 
 ## Outer and Inner puzzles
 
-A common design pattern, and one of the most powerful features of Chialisp, is the ability to have an outer smart contract the "wraps" an inner puzzle.  This concept is extremely handy because it allows a coin to retain all of it's standard functionality and programmability within the inner puzzle, but be bound to an extra set of rules by the outer puzzle.
+A common design pattern, and one of the most powerful features of ChiaLisp, is the ability to have an outer smart contract the "wraps" an inner puzzle.  This concept is extremely handy because it allows a coin to retain all of it's standard functionality and programmability within the inner puzzle, but be bound to an extra set of rules by the outer puzzle.
 
 For this example, we're going to continue with our password locking, but this time we're going to require that every time the coin is spent, it requires a new password to be set.  Let's look at all the code and then we'll break it down:
 
@@ -203,7 +203,7 @@ You may notice that we imported a new library called `curry-and-treehash`.  We'l
 
 First, let's talk about the arguments.  When you create this puzzle for the first time you need to curry in 3 things: `MOD_HASH` which is the tree hash of this code, `PASSWORD_HASH` which is the hash of the password that will unlock this coin, and `INNER_PUZZLE` which is a completely separate puzzle that will have its own rules about how the coin can be spent.
 
-Chialisp puzzles have the tendency to be read from the bottom up, so lets start with this chunk:
+ChiaLisp puzzles have the tendency to be read from the bottom up, so lets start with this chunk:
 
 ```lisp
 ; main
@@ -228,7 +228,7 @@ All that's happening here is that we're making sure the password is correct and,
 )
 ```
 
-Recursion is the foundation of Chialisp and functions like these very commonly show up when writing it.  In order to iterate through the list of conditions, we first check if there are still items left (remember that an empty list `()` or **nil** evaluates to false). Then, we morph the first condition and concatenate it with the recursive output of the rest of the list.  In the end, we will have the same list of items in the same order, but all of them will have passed thru `morph-condition`.
+Recursion is the foundation of ChiaLisp and functions like these very commonly show up when writing it.  In order to iterate through the list of conditions, we first check if there are still items left (remember that an empty list `()` or **nil** evaluates to false). Then, we morph the first condition and concatenate it with the recursive output of the rest of the list.  In the end, we will have the same list of items in the same order, but all of them will have passed thru `morph-condition`.
 
 ```lisp
 ;; tweak `CREATE_COIN` condition by wrapping the puzzle hash, forcing it to be a password locked coin
@@ -260,6 +260,6 @@ However, all we care about is generating the correct *puzzle hash* for the next
 
 And that's it!  When this coin is created, it can only be spent by a password that hashes to the curried in PASSWORD_HASH.  The inner puzzle can be anything that you want including other smart contracts that have their own inner puzzles.  Whatever coins get created as a result of that inner puzzle will be "wrapped" by this same outer puzzle ensuring that every child of this coin is locked by a password *forever*.
 
-We created a simple coin, but you can see the potential of this. You can enforce a set of rules not only on a coin that you lock up, but on *every* descendant coin.  Not only that, the rules can be enforced *on top of other smart contracts*.  In the Chialisp ecosystem, all smart contracts are interoperable with each other unless otherwise specified by a parent smart contract. The possibilities are endless and represent the vast programmability that Chialisp enables for coins.
+We created a simple coin, but you can see the potential of this. You can enforce a set of rules not only on a coin that you lock up, but on *every* descendant coin.  Not only that, the rules can be enforced *on top of other smart contracts*.  In the ChiaLisp ecosystem, all smart contracts are interoperable with each other unless otherwise specified by a parent smart contract. The possibilities are endless and represent the vast programmability that ChiaLisp enables for coins.
 
 In the next section, we'll talk about the standard transaction format on the Chia network.

docs/deeper_into_clvm.md

@@ -6,7 +6,7 @@ title: 3 - Deeper into CLVM
 This guide directly continues on from [part 1](/docs/) so if you haven't read that, please do so before reading this.
 
 This section of the guide will cover how ChiaLisp relates to transactions and coins on the Chia network.
-If there are any terms that you aren't sure of, be sure to check the [glossary](/docs/glossary).
+If there are any terms that you are not sure of, be sure to check the [glossary](/docs/glossary).
 
 ## Lazy Evaluation in ChiaLisp
 

docs/faq.md

@@ -1,5 +1,5 @@
 ---
-id: faq
+id: FAQ
 title: ChiaLisp and CLVM FAQ
 sidebar_label: ChiaLisp and CLVM FAQ
 ---