Move imported files into metafang/ dirHEADmaster

this metaprogramming attempt was started outside, and then imported here
5124eb80701523ac16928219e9a1031eded128ef..bc8c20d1e93b5c18e8915d356e74024092a74ce8

3 files changed, 0 insertions, 91 deletions

diff --git a/cm/ex01.lua b/cm/ex01.lua
deleted file mode 100644
index f92ec2a..0000000
--- a/cm/ex01.lua
+++ /dev/null
@@ -1,27 +0,0 @@
--- Environment is loaded with the utils (as metatable.__index)
--- Global vars (aka properties on env) will be read as decls
-
--- TERMINOLOGY:
--- decl: a property somewhere, the property name and the value makes up the declaration
--- type: a value (perhaps a part of a decl), which contains a type tag ("struct", "union", "alias", etc.) and extra info for that kind of type
-
--- _struct, _union, _alias, etc. are type construction helpers.
--- They take the essential info, and returns a value properly decorated. For example it might just add a property {_tag="struct"}, or perhaps more.
-
--- name implied by property key here
-Bar = _struct({
-    -- _t: Loads another type by its name. Return the type, or a placeholder if the type is not yet available
-    --     Useful recursive definitions
-    --     Undefined type errors generated on the referential resolution pass (i.e. not immediately)
-    field1 = _t("i32"),
-    field2 = _t("string"),
-    -- Deferred loading as described above
-    compound_field = _t("Foo"),
-})
-
-uint32 = _alias(_t("u32"))
-
--- Note, defined after Bar!
-Foo = _struct({
-    n = _t("i32"),
-})
diff --git a/cm/ex02.decl b/cm/ex02.decl
deleted file mode 100644
index d695e33..0000000
--- a/cm/ex02.decl
+++ /dev/null
@@ -1,22 +0,0 @@
-// 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)
-// overloading discouraged, because runtime has to do extra work dispatching
-// declare functions outside, with `this` keyword marking receiver
-// - in C, func -> prefixed with reciever type, 1st arg is reciever pointer
-// - in C++, func -> member function
-// - lua (or whatever else), reciever type correspondingly
-
-Foo {
-    data
-}
-
-// C: mangling
-// C++: overloading
-// Lua: generate binding with type detection based dispatcher
-fn some_function(this: Foo, arg: i32)
-fn some_function(this: Foo)
-
-// alternative: use S-expression, get rid of parsing step?
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
-
-