lua literals loading draft, and contemplations on the bigger picture Cm language

2 files changed, 40 insertions, 0 deletions

diff --git a/cm/ex02.decl b/cm/ex02.decl
index 394d446..d695e33 100644
--- a/cm/ex02.decl
+++ b/cm/ex02.decl
@@ -1,3 +1,5 @@
+// Declarations only version of Cm (like mojo/protobuf? not sure)
+
 // assume special receiver (as opposed to smalltalk/objC style message passing)
 //    -- actually, on second thought, this has nothing to do with dispatching (and smalltalk is single dispatch)
 //    -- (no touching multiple dispatch since that's equivalent to reinventing a new language)
diff --git a/cm/ex03.cm b/cm/ex03.cm
new file mode 100644
index 0000000..34275df
--- /dev/null
+++ b/cm/ex03.cm
@@ -0,0 +1,38 @@
+// Hypothetical, fully ledged version of Cm, at compile time, using a superset of the runtime language
+// with macros, and an escape hatch into native code (C or whatever)
+
+// Language structurally, a bit like Nim:
+// - the scripting language itself
+// - macros, which are functions from language itself operating on special AST values at compile time
+// - (NEW) native escape hatch, kind of literate programming style, expanding into native program source code at compile time
+
+// So the compile procedure is as follows:
+// - build interpreter (native source code) from source
+// - init interpreter
+// - load program source code, evaluate to produce
+//   - an environment image (bytecode of scripting constructs), and
+//   - native program source (text of things produced by native escape hatch, plus interpreter source code itself, plus auto generated bindings)
+// - build native program
+// And run procedure is:
+// - init interpreter (<- the PE/mach-o/ELF entrypoint here)
+// - init native program parts (<- i.e. the escape hatches don't generate an actual main() func, instead a customly named init() func that gets called by the generated machinery)
+// - load bindings
+// - load environment image
+// - run native program entrypoint
+// The order of native program entrypoint vs. environment loading might be reversed. Depending on how it makes sense.
+// Or maybe there will be 2 parts, the native program *init* and *start*. Former would be like the _mainCRTStartup() that initializes global variables, etc.
+
+// REQUIREMENT FOR NATIVE PROGRAM SOURCE:
+// Must be nicely readable.
+// We plan on completely reusing the traditional native program debuggers, e.g. GDB for debugging
+// The interpreter can then have its own debugging system
+// Problem: How to do mixed language debugging? like stepping into a native function, this is a lot of work/hacks to wrap on top of e.g. GDB
+// SIDE THOUGHT:
+// should bindings be baked into the environment image (i.e. design the bytecode format to include this? however it should be done; can't really imagine it now?)
+// or should they be generated e.g. `bind_function("func_name", &func_written_in_C);`?
+
+// terminology akin to Janet (from _Janet for Mortals_):
+// compile: evaluating the program sources to produce an environment
+// runtime: evaluating the environment
+
+