diff options
Diffstat (limited to 'cm/ex03.cm')
| -rw-r--r-- | cm/ex03.cm | 42 |
1 files changed, 0 insertions, 42 deletions
diff --git a/cm/ex03.cm b/cm/ex03.cm deleted file mode 100644 index 417799f..0000000 --- a/cm/ex03.cm +++ /dev/null @@ -1,42 +0,0 @@ -// 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 - - |
