Have fixed array pass by ref in compiler

Roadmap.md

@@ -3,26 +3,26 @@
 This is where I keep track of what to do next ...
 
 ## Near-Term
-- Finish compiler implementation (parity with interpreter features)
-  - Array pass by reference
-- Write a non-trivial app in EightBall to discover the pain points
+- Write a non-trivial app in EightBall to discover the pain points and the bugs that `unittest.8b` doesn't reveal
+- Try to squeeze the interpreter / compiler code down a bit to save memory.  There is duplication that can be eliminated by reorganizing the logic and/or factoring out into functions.
 
 ## Medium-Term
 - Wishlist features:
-  - Multidimensional arrays
-    - 2D array is implemented as array of pointers to arrays of `word` or `byte`.
-    - 3D array is implemented as array of pointers to array of pointers to arrays of `word` or `byte`.
-    - etc.
   - Array initializer lists:
     - `word xyz[3] = {123, 456, 789}`
   - String initializer:
     - `byte qq[10] = "abcde"` - will also add null terminator to string
   - A way to pass string literals as subroutine arguments
+  - Multidimensional arrays
+    - 2D array is implemented as array of pointers to arrays of `word` or `byte`.
+    - 3D array is implemented as array of pointers to array of pointers to arrays of `word` or `byte`.
+    - etc.
   - Module system
     - Would be good to make bytecode relocatable by using relative addresses
     - Need to add new relative jump / branch instructions for this)
     - Drawback is it makes the code harder to read for humans, but this can be overcome with better tools
     - Need to think about how a module system should work
+    - Which is more useful: dynamic loading of modules at runtime, or static linking?
 - Optimize virtual machine bytecodes, based on study of real code
   - For example, it would be good to have an instruction to drop n bytes from call stack rather than repeated `POP`, `DROP` as the compiler currently does.
 
@@ -32,5 +32,5 @@ This is where I keep track of what to do next ...
 
 # Ground Rules
 Features will only be added if:
-1. They do not increase the code size so much that it is no longer practical to run EightBall on Apple II and C64.  (VIC20+32K is already a tight fit.)
+1. They do not increase the code size so much that it is no longer practical to run EightBall on Apple II and C64.  (VIC20+32K is already a tight fit.)  Contributions that *reduce* the code size are especially welcome!
 2. Language features must have both an interpreter and compiler implementation.