add Memory Management section to STYLEGUIDE

STYLEGUIDE

@@ -130,21 +130,23 @@ When authoring a new module, use this as a base plate:
 	}
 
 
-Bindings
---------
+Memory Management
+-----------------
 
-Binding modules should default to static linking and take
-an optional '#module_parameter' to link dynamically.
-Libraries should be pinned to a specific version, and all
-binaries (.dll, .dylib, etc.) *must* be checked into
-source control. If possible, use the release build of the
-library that includes debug information.
+If a custom type needs memory to function, it should
+always assume the memory it requested came from an arena
+allocator. This means it is the responsibility of the
+arena to free the memory, not the custom data type.
 
-Bindings should stay as close as possible to the original
-library. To jai-ify the bindings, create a submodule
-called 'wrapper' that import and wraps the api.
+In other words:
 
-See: 'thirdparty/raylib' for example bindings.
+Do *not* add procedures that 'free' or 'delete' the memory
+allocated by the data type.
+
+Instead, add procedures that 'reset' the data type,
+allowing the already allocated memory to be reused. For
+examples, see the 'reset' procedures in 'jc/kv'
+or 'jc/array'.
 
 
 OS-Specific Code
@@ -177,3 +179,19 @@ When writing code for a specific architecture, use
 the 'jc/arch' module. NEVER create a new file unless
 absolutely needed.
 
+
+Bindings
+--------
+
+Binding modules should default to static linking and take
+an optional '#module_parameter' to link dynamically.
+Libraries should be pinned to a specific version, and all
+binaries (.dll, .dylib, etc.) *must* be checked into
+source control. If possible, use the release build of the
+library that includes debug information.
+
+Bindings should stay as close as possible to the original
+library. To jai-ify the bindings, create a submodule
+called 'wrapper' that import and wraps the api.
+
+See: 'thirdparty/raylib' for example bindings.