docs: spelling mistakes correction

c-api/drive_system_h.md

@@ -1,7 +1,8 @@
 
+
 # drive_system.h
 
-When accessing the file system through Toy (such as with the runner library), it's best practice to utilize the drive system - this system (tries to) prevent malicious accessing of files outside of the designated folders. It does this by causing an error when a script tries to access a parent directory.
+When accessing the file system through Toy (such as with the runner library), it's best practice to utilize the drive system - this system (tries to) prevent malicious accessing of files outside the designated folders. It does this by causing an error when a script tries to access a parent directory.
 
 To use the drive system, first you must designate specific folders which can be accessed, like so:
 
@@ -9,19 +10,19 @@ To use the drive system, first you must designate specific folders which can be
 #include "drive_system.h"
 
 int main(int argc, char* argv[]) {
-	//the drive system uses a LiteralDictionary, which must be initialized with this
-	Toy_initDriveSystem();
+    //the drive system uses a LiteralDictionary, which must be initialized with this
+    Toy_initDriveSystem();
 
-	Toy_setDrivePath("scripts", "assets/scripts");
-	Toy_setDrivePath("sprites", "assets/sprites");
-	Toy_setDrivePath("fonts", "assets/fonts");
+    Toy_setDrivePath("scripts", "assets/scripts");
+    Toy_setDrivePath("sprites", "assets/sprites");
+    Toy_setDrivePath("fonts", "assets/fonts");
 
-	//TODO: do you stuff here
+    //TODO: do you stuff here
 
-	//clean up the drive dictionary when you're done
-	Toy_freeDriveSystem();
+    //clean up the drive dictionary when you're done
+    Toy_freeDriveSystem();
 
-	return 0;
+    return 0;
 }
 ```
 
@@ -43,7 +44,7 @@ This function cleans up after the drive system is no longer needed.
 
 ### void Toy_setDrivePath(char* drive, char* path)
 
-This function sets a key-value pair in the drive system. It uses C strings, since its intended to be called directly from `main()`.
+This function sets a key-value pair in the drive system. It uses C strings, since it is intended to be called directly from `main()`.
 
 ### Toy_Literal Toy_getDrivePathLiteral(Toy_Interpreter* interpreter, Toy_Literal* drivePathLiteral)
 

c-api/repl_tools_h.md

@@ -1,7 +1,8 @@
 
+
 # repl_tools.h
 
-This header provides a number of tools for compiling and running Toy, and is used primarily by the repl. However, it can also be modified and used by any host program with a little effort.
+This header provides a number of tools for compiling and running Toy, and is used primarily by the REPL. However, it can also be modified and used by any host program with a little effort.
 
 This is not a core part of Toy or a library, and as such `repl_tools.h` and `repl_tools.c` can both be found in the `repl/` folder.
 

c-api/toy_common_h.md

@@ -1,7 +1,8 @@
 
+
 # toy_common.h
 
-This file is generally included in most header files within Toy, as it is where the TOY_API macro is defined. It also has some utilities intended for use only by the repl.
+This file is generally included in most header files within Toy, as it is where the TOY_API macro is defined. It also has some utilities intended for use only by the REPL.
 
 ## Defined Macros
 
@@ -11,7 +12,7 @@ This definition of this macro is platform-dependant, and used to enable cross-pl
 
 ### TOY_VERSION_MAJOR
 
-The current major version of Toy. This value is embedded into the bytecode, and the interpreter will refuse to run bytecode with a major version that does not match it’s own version.
+The current major version of Toy. This value is embedded into the bytecode, and the interpreter will refuse to run bytecode with a major version that does not match its own version.
 
 This value MUST fit into an unsigned char.
 
@@ -33,4 +34,4 @@ The current build version of Toy. This value is embedded into the bytecode.
 
 This evaluates to a c-string, which contains build information such as compilation date and time of the interpreter. When in verbose mode, the compiler will display a warning if the build version of the bytecode does not match the build version of the interpreter.
 
-This macro may also be used to store additonal information about forks of the Toy codebase.
+This macro may also be used to store additional information about forks of the Toy codebase.

c-api/toy_compiler_h.md

@@ -9,7 +9,7 @@ During the collation step, everything from the core program’s execution instru
 
 ## Define Functions
 
-Executing the following functions out-of-order causes undefiend behaviour.
+Executing the following functions out-of-order causes undefined behaviour.
 
 ### void Toy_initCompiler(Toy_Compiler* compiler)
 

c-api/toy_h.md

@@ -1,4 +1,5 @@
 
+
 # toy.h - A Toy Programming Language
 
 If you're looking how to use Toy directly, try https://toylang.com/
@@ -50,7 +51,7 @@ You probably won't use these directly, but they're a good learning opportunity.
 
 `Toy_Scope` holds the variables of a specific scope within Toy - be it a script, a function, a block, etc. Scopes are also where the type system lives at runtime. They use identifier literals as keys, exclusively.
 
-`Toy_RefString` is a utility class that wraps traditional C strings, making them less memory intensive and faster to copy and move. In reality, since strings are considered immutable, multiple variables can point to the same string to save memory, and you can just create a new one of these vars pointing to the original rather than copying entirely for a speed boost. This module has it's own memory allocator system that is plugged into the main memory allocator.
+`Toy_RefString` is a utility class that wraps traditional C strings, making them less memory intensive and faster to copy and move. In reality, since strings are considered immutable, multiple variables can point to the same string to save memory, and you can just create a new one of these vars pointing to the original rather than copying entirely for a speed boost. This module has its own memory allocator system that is plugged into the main memory allocator.
 
 `Toy_RefFunction` acts similarly to `Toy_RefString`, but instead operates on function bytecode.
 

c-api/toy_interpreter_h.md

@@ -5,7 +5,7 @@ This header defines the interpreter structure, which is the beating heart of Toy
 
 `Toy_Interpreter` is a stack-based, bytecode-driven interpreter with a number of customisation options, including "hooks"; native C functions wrapped in `Toy_Literal` instances, injected into the interpreter in order to give the Toy scripts access to libraries via the `import` keyword. The hooks, when invoked this way, can then inject further native functions into the interpreter's current scope. Exactly which hooks are made available varies by host program, but `standard` is the most commonly included one.
 
-Another useful customisation feature is the ability to redicrect output from the `print` and `assert` keywords, as well as any internal errors that occur. This can allow you to add in a logging system, or even hook the `print` statement up to some kind of HUD.
+Another useful customisation feature is the ability to redirect output from the `print` and `assert` keywords, as well as any internal errors that occur. This can allow you to add in a logging system, or even hook the `print` statement up to some kind of HUD.
 
 ## Defined Interfaces
 
@@ -31,7 +31,7 @@ The identifier of the library (its name) is passed in as a `Toy_Literal`, as is
 import standard as std;
 ```
 
-Conventionally, when an alias is given, all of the functions should instead be inserted into a `Toy_LiteralDictionary` which is then inserted into the scope with the alias as its identifier.
+Conventionally, when an alias is given, all the functions should instead be inserted into a `Toy_LiteralDictionary` which is then inserted into the scope with the alias as its identifier.
 
 ## Defined Functions
 
@@ -45,7 +45,7 @@ This function takes a `Toy_Interpreter` and `bytecode` (as well as the `length`
 
 If the given bytecode's embedded version is not compatible with the current interpreter, then this function will refuse to execute.
 
-Re-using a `Toy_Interpreter` instance without first resetting it is possible (that's how the repl works), however doing so may have unintended consequences if the scripts are not intended to be used in such a way. Any variables declared will persist.
+Re-using a `Toy_Interpreter` instance without first resetting it is possible (that's how the REPL works), however doing so may have unintended consequences if the scripts are not intended to be used in such a way. Any variables declared will persist.
 
 ### void Toy_resetInterpreter(Toy_Interpreter* interpreter)
 
@@ -60,11 +60,11 @@ This function frees any scopes that the scripts have built up, and generates a n
 
 ### void Toy_freeInterpreter(Toy_Interpreter* interpreter)
 
-This function frees a `Toy_Interpreter`, clearing all of the memory used within. That interpreter is no longer valid for use, and must be re-initialized.
+This function frees a `Toy_Interpreter`, clearing all the memory used within. That interpreter is no longer valid for use, and must be re-initialized.
 
 ### bool Toy_injectNativeFn(Toy_Interpreter* interpreter, const char* name, Toy_NativeFn func)
 
-This function will inject the given native function `func` into the `Toy_Interpreter`'s current scope, with the identifer as `name`. Both the name and function will be converted into literals internally before being stored. It will return true on success, otherwise it will return false.
+This function will inject the given native function `func` into the `Toy_Interpreter`'s current scope, with the identifier as `name`. Both the name and function will be converted into literals internally before being stored. It will return true on success, otherwise it will return false.
 
 The primary use of this function is within hooks.
 
@@ -86,12 +86,12 @@ This utility function will find a `Toy_literal` within the `Toy_Interpreter`'s s
 
 ### bool Toy_parseIdentifierToValue(Toy_Interpreter* interpreter, Toy_Literal* literalPtr)
 
-Sometimes, native functions will receive `Toy_Literal` identifiers instead of the values - the correct values can be retreived from the given interpreter's scope using the following pattern:
+Sometimes, native functions will receive `Toy_Literal` identifiers instead of the values - the correct values can be retrieved from the given interpreter's scope using the following pattern:
 
 ```c
 Toy_Literal foobarIdn = foobar;
 if (TOY_IS_IDENTIFIER(foobar) && Toy_parseIdentifierToValue(interpreter, &foobar)) {
-	freeLiteral(foobarIdn); //remember to free the identifier
+    freeLiteral(foobarIdn); //remember to free the identifier
 }
 ```
 
@@ -101,11 +101,11 @@ This function sets the function called by the `print` keyword. By default, the f
 
 ```c
 static void printWrapper(const char* output) {
-	printf("%s\n", output);
+    printf("%s\n", output);
 }
 ```
 
-Note: The above is a very minor lie - in reality there are some preprocessor directives to allow the repl's `-n` flag to work.
+Note: The above is a very minor lie - in reality, there are some preprocessor directives to allow the REPL's `-n` flag to work.
 
 ### void Toy_setInterpreterAssert(Toy_Interpreter* interpreter, Toy_PrintFn assertOutput)
 
@@ -113,7 +113,7 @@ This function sets the function called by the `assert` keyword on failure. By de
 
 ```c
 static void assertWrapper(const char* output) {
-	fprintf(stderr, "Assertion failure: %s\n", output);
+    fprintf(stderr, "Assertion failure: %s\n", output);
 }
 ```
 
@@ -123,6 +123,6 @@ This function sets the function called when an error occurs within the interpret
 
 ```c
 static void errorWrapper(const char* output) {
-	fprintf(stderr, "%s", output); //no newline
+    fprintf(stderr, "%s", output); //no newline
 }
 ```

c-api/toy_lexer_h.md

@@ -23,6 +23,6 @@ Private functions are not intended for general use.
 
 ### void Toy_private_setComments(Toy_Lexer* lexer, bool enabled)
 
-This function sets whether comments are allowed within source code. By default, comments are allowed, and are only disabled in the repl.
+This function sets whether comments are allowed within source code. By default, comments are allowed, and are only disabled in the REPL.
 
 Private functions are not intended for general use.

c-api/toy_literal_array_h.md

@@ -1,9 +1,10 @@
 
+
 # literal_array.h
 
 This header defines the array structure, which manages a series of `Toy_Literal` instances in sequential memory. The array does not take ownership of given literals, instead it makes an internal copy.
 
-The array type is one of two fundemental data structures used throughout Toy - the other is the dictionary.
+The array type is one of two fundamental data structures used throughout Toy - the other is the dictionary.
 
 ## Defined Functions
 

c-api/toy_literal_dictionary_h.md

@@ -1,17 +1,18 @@
 
+
 # toy_literal_dictionary.h
 
 This header defines the dictionary structure (as well as the private entry structure), which manages a series of `Toy_Literal` instances stored in a key-value hash map. The dictionary does not take ownership of given literals, instead it makes an internal copy.
 
-The dictionary type is one of two fundemental data structures used throughout Toy - the other is the array.
+The dictionary type is one of two fundamental data structures used throughout Toy - the other is the array.
 
 ## Defined Macros
 
 ### TOY_DICTIONARY_MAX_LOAD
 
-If the contents of a dictionary exceeds this percentage of it's capacity, then a new buffer is created, the old contents are copied over one-by-one, and the original buffer is freed.
+If the contents of a dictionary exceeds this percentage of its capacity, then a new buffer is created, the old contents are copied over one-by-one, and the original buffer is freed.
 
-Since this process can be memory and time intensive, a configurable macro is used to allow for fine-grained control across the lang.
+Since this process can be memory and time intensive, a configurable macro is used to allow for fine-grained control across the language.
 
 The current default value is `0.75`, representing 75% capacity.
 

c-api/toy_literal_h.md

@@ -1,4 +1,5 @@
 
+
 # toy_literal.h
 
 This header defines the literal structure, which is used extensively throughout Toy to represent values of some kind.
@@ -65,7 +66,7 @@ The following macros are used to cast a literal to a specific C type to be used.
 
 The following macros are used to create a new literal, with the given `value` as it's internal value.
 
-* `TOY_TO_NULL_LITERAL` - does not need parantheses
+* `TOY_TO_NULL_LITERAL` - does not need parentheses
 * `TOY_TO_BOOLEAN_LITERAL(value)`
 * `TOY_TO_INTEGER_LITERAL(value)`
 * `TOY_TO_FLOAT_LITERAL(value)`
@@ -85,9 +86,9 @@ The following macros are utilities used throughout Toy's internals, and are avai
 
 ### TOY_IS_TRUTHY(x)
 
-Returns true of the literal `x` is truthy, otherwise it returns false.
+Returns true if the literal `x` is truthy, otherwise it returns false.
 
-Currently, every value is considered truthy except `false`, which is falsy and `null`, which is neither true or false.
+Currently, every value is considered truthy except `false`, which is falsy and `null`, which is neither true nor false.
 
 ### TOY_AS_FUNCTION_BYTECODE_LENGTH(lit)
 
@@ -107,9 +108,9 @@ This macro is only valid on `TOY_LITERAL_IDENTIFIER`.
 
 ### TOY_TYPE_PUSH_SUBTYPE(lit, subtype)
 
-When building a complex type, such as the type of an array or dictionary, you may need to specify inner types. Use this to push a `subtype`. calling `Toy_freeLiteral()` on the outermost type should clean up all inner types, as expected.
+When building a complex type, such as the type of an array or dictionary, you may need to specify inner types. Use this to push a `subtype`. Calling `Toy_freeLiteral()` on the outermost type should clean up all inner types, as expected.
 
-This macro returns the index of the newly pushed value within it's parent.
+This macro returns the index of the newly pushed value within its parent.
 
 This macro is only valid on `TOY_LITERAL_TYPE`, for both `type` and `subtype`.
 
@@ -135,7 +136,7 @@ This function returns a copy of the given literal. Literals should never be copi
 
 This checks to see if two given literals are equal.
 
-When an integer and a float are compared, the integer is cooerced into a float for the duration of the call.
+When an integer and a float are compared, the integer is coerced into a float for the duration of the call.
 
 Arrays or dictionaries are equal only if their keys and values all equal. Likewise, types only equal if all subtypes are equal, in order.
 
@@ -145,7 +146,7 @@ Functions and opaques are never equal to anything, while values with the type `T
 
 This finds the hash of a literal, for various purposes. Different hashing algorithms are used for different types, and some types can't be hashed at all.
 
-types that can't be hashed are
+Types that can't be hashed are
 
 * all kinds of functions
 * type

c-api/toy_memory_h.md

@@ -1,7 +1,8 @@
 
+
 # toy_memory.h
 
-This header defines all of the memory management utilities. Any and all heap-based memory management goes through these utilities.
+This header defines all the memory management utilities. Any and all heap-based memory management goes through these utilities.
 
 A default memory allocator function is used internally, but it can be overwritten for diagnostic and platform related purposes.
 
@@ -45,7 +46,7 @@ Any and all memory allocator functions should:
 
 * Take a `pointer` to a previously allocated block of memory, or `NULL`
 * Take the `oldSize`, which is the previous size of the `pointer` allocated, in bytes (`oldSize` can be 0)
-* Take the `newSize`, which is the new size of the buffer to be allocaated, in bytes (`newSize` can be 0)
+* Take the `newSize`, which is the new size of the buffer to be allocated, in bytes (`newSize` can be 0)
 * Return the newly allocated buffer, or `NULL` if `newSize` is zero
 * Return `NULL` on error
 

c-api/toy_parser_h.md

@@ -67,6 +67,6 @@ This function should be called repeatedly until it returns `NULL`, indicating th
 
 ### void Toy_freeASTNode(Toy_ASTNode* node)
 
-This function cleans up any valid instance of `Toy_ASTNode` pointer passed to it. It is most commonly used to clean up the values returned by `Toy_scanParser`, after they have been passsed to `Toy_writeCompiler`, or when the node is an error node.
+This function cleans up any valid instance of `Toy_ASTNode` pointer passed to it. It is most commonly used to clean up the values returned by `Toy_scanParser`, after they have been passed to `Toy_writeCompiler`, or when the node is an error node.
 
 Note: this function is *actually* defined in toy_ast_node.h, but documented here, because this is where it matters most.

c-api/toy_reffunction_h.md

@@ -1,7 +1,8 @@
 
+
 # toy_reffunction.h
 
-This header defines the Toy_RefFunction structure, as well as all of the related utilities.
+This header defines the Toy_RefFunction structure, as well as all the related utilities.
 
 See [Toy_RefString](toy_refstring_h.md) for more information about the reference pattern.
 

c-api/toy_refstring_h.md

@@ -1,9 +1,10 @@
 
+
 # toy_refstring.h
 
-This header defines the structure `Toy_RefString`, as well as all of the related utilities.
+This header defines the structure `Toy_RefString`, as well as all the related utilities.
 
-[refstring](https://github.com/Ratstail91/refstring) is a stand-alone utility written to reduce the amount of memory manipulation used within Toy. It was independantly written and tested, before being incorporated into Toy proper. As such it has it's own memory management API, which by default is tied into Toy's [core memory API](toy_memory_h.md).
+[refstring](https://github.com/Ratstail91/refstring) is a stand-alone utility written to reduce the amount of memory manipulation used within Toy. It was independently written and tested, before being incorporated into Toy proper. As such, it has its own memory management API, which by default is tied into Toy's [core memory API](toy_memory_h.md).
 
 Instances of `Toy_RefString` are reference counted - that is, rather than copying an existing string in memory, a pointer to the refstring is returned, and the internal reference counter is increased by 1. When the pointer is no longer needed, `Toy_DeleteRefString` can be called; this will decrement the internal reference counter by 1, and only free it when it reaches 0. This has multiple benefits, when used correctly:
 
@@ -62,8 +63,8 @@ This function exposes the interal cstring of `refString`. Only use this function
 
 ### bool Toy_equalsRefString(Toy_RefString* lhs, Toy_RefString* rhs)
 
-This function returns true when the two refstrings are either the same refstring, or contain the same value. Otherwise it returns false.
+This function returns true when the two refstrings are either the same refstring, or contain the same value. Otherwise, it returns false.
 
 ### bool Toy_equalsRefStringCString(Toy_RefString* lhs, char* cstring)
 
-This function returns true when the `refString` contains the same value as the `cstring`. Otherwise it returns false.
+This function returns true when the `refString` contains the same value as the `cstring`. Otherwise, it returns false.

c-api/toy_scope_h.md

@@ -1,9 +1,10 @@
 
+
 # toy_scope.h
 
-This header defines the scope structure, which stores all of the variables used within a given block of code.
+This header defines the scope structure, which stores all the variables used within a given block of code.
 
-Scopes are arranged into a linked list of ancestors, each of which is reference counted. When a scope is popped off the end of the chain, every ancestor scope has it's reference counter reduced by 1 and, if any reach 0, they are freed.
+Scopes are arranged into a linked list of ancestors, each of which is reference counted. When a scope is popped off the end of the chain, every ancestor scope has its reference counter reduced by 1 and, if any reach 0, they are freed.
 
 This is also where Toy's type system lives.
 
@@ -15,7 +16,7 @@ This function creates a new `Toy_scope` with `scope` as it's ancestor, and retur
 
 ### Toy_Scope* Toy_popScope(Toy_Scope* scope)
 
-This function frees the given `scope`, and returns it's ancestor.
+This function frees the given `scope`, and returns its ancestor.
 
 ### Toy_Scope* Toy_copyScope(Toy_Scope* original)
 
@@ -35,7 +36,7 @@ This function checks to see if a given variable with the name `key` has been pre
 
 ### bool Toy_setScopeVariable(Toy_Scope* scope, Toy_Literal key, Toy_Literal value, bool constCheck)
 
-This function sets an existing variable named `key` to the value of `value`. This function fails if `constCheck` is true and the given key's type has the constaant flag set. It also fails if the given key doesn't exist.
+This function sets an existing variable named `key` to the value of `value`. This function fails if `constCheck` is true and the given key's type has the constant flag set. It also fails if the given key doesn't exist.
 
 This function returns true on success, otherwise it returns false.