From 81cab430b58b75fe0a6c75722908481dd4d9d55a Mon Sep 17 00:00:00 2001 From: rtk0c Date: Wed, 15 Oct 2025 20:31:31 +0000 Subject: Move imported files into metafang/ dir this metaprogramming attempt was started outside, and then imported here 5124eb80701523ac16928219e9a1031eded128ef..bc8c20d1e93b5c18e8915d356e74024092a74ce8 --- metafang/cm/ex03.cm | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 metafang/cm/ex03.cm (limited to 'metafang/cm/ex03.cm') diff --git a/metafang/cm/ex03.cm b/metafang/cm/ex03.cm new file mode 100644 index 0000000..417799f --- /dev/null +++ b/metafang/cm/ex03.cm @@ -0,0 +1,42 @@ +// 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);`? + +// REUSING EXSITING SCRIPTING LANGUAGE +// We don't want to reimplement a language from scratch +// Hacking e.g. PUC-Lua's parser? Kind of like Terra + +// terminology akin to Janet (from _Janet for Mortals_): +// compile: evaluating the program sources to produce an environment +// runtime: evaluating the environment + + -- cgit v1.3.1