Some more stdlib fun and example code and cosmetic changes. (0.38.15)

docs/style-guide.md

@@ -3,23 +3,60 @@
 Conventions for writing C and Fun code in this repository.
 
 ## General principles
+
 - Two-space indentation. No tabs.
 - Keep lines reasonably short (~100 cols). Wrap thoughtfully.
 - Prefer explicit over implicit; favor clarity.
 
 ## C (C99)
-- Indentation: two spaces, K&R-ish braces.
+
+- Indentation: four spaces, K&R-ish braces.
 - Naming: `snake_case` for functions and variables; `CAPS_SNAKE` for macros.
 - Error handling: return error codes or booleans; avoid hidden globals.
 - Headers: minimize includes in headers; forward-declare where practical.
 - Memory: clearly document ownership; free what you allocate.
 
 ## Fun language
+
 - Indentation: two spaces.
 - Naming: `snake_case` for functions/variables; `PascalCase` for classes/constructors.
 - Modules: one primary concept per file; export a minimal, cohesive API.
 - Idioms: prefer arrays and maps over ad-hoc structures; keep functions small.
 
 ## Formatting and tools
+
 - No auto-formatters required; follow these simple rules.
 - Keep diffs small and focused; avoid reformat-only commits.
+
+## Additional details (merged from legacy MVP draft)
+
+This section consolidates practical guidelines that were previously kept in docs/style_guide.md.
+
+1. Files and headers
+- Keep the standard header block with license and date when editing stdlib files.
+
+2. Naming
+- Functions and variables: snake_case (e.g., parse_int, is_some).
+- Classes: PascalCase (e.g., DateTime).
+- Constants: ALL_CAPS when truly constant.
+
+3. Layout
+- Indent with two spaces; no tabs.
+- One statement per line; no trailing spaces.
+- Use blank lines sparingly to separate logical blocks.
+
+4. Comments
+- Line comments with //; block comments with /* ... */ for file headers and longer notes.
+
+5. Collections
+- Prefer [] for arrays and {"key": value} for dictionaries; use has_key() before subscripting unknown keys.
+
+6. Error handling
+- Prefer Result and Option helpers from lib/utils over ad-hoc nil checks.
+- Avoid unwrap() in library code; propagate errors using and_then()/or_else() patterns.
+
+7. Examples
+- Keep examples executable via shebang: #!/usr/bin/env fun
+- Print informative labels for outputs.
+
+This guide will evolve. Contributions and suggestions are welcome.

docs/testing.md

@@ -25,7 +25,7 @@ Release profile example:
 
 ```
 cmake --build build_release --target test_opcodes && ./build/test_opcodes
-``>
+```
 
 If `fun_test` exists in your configuration:
 
@@ -45,7 +45,8 @@ ctest --test-dir build -j
 - C/C++/VM-side tests: look for existing tests under `src` or `spec` and mirror the structure. Add a new source and register it in CMake with an executable or via `add_test()`.
 - Fun-level examples as tests: minimal scripts under `examples/` can act as smoke tests and are runnable via `./play.fun`. Consider adding a new example for new features and have CI invoke a subset.
 
-Guidelines:
+### Guidelines:
+
 - Keep each test focused; prefer several small tests over one monolith.
 - Avoid nondeterminism; set seeds where randomness is involved.
 - Make tests independent of the working directory unless the behavior under test is precisely path resolution.