Below is a copy of a discord "conversion" between (mostly) me and ezysigh about problems with compile time execution and maybe a partial solution to the problem. This is recorded here for future reference.
n.b. It includes all my amazing typos, grammatical errors, and swearing.


[10:30 PM] ezysigh: Have you added meta/compiletime stuff yet?
[10:30 PM] gingerBill: Not yet as I'm still designing it.
[10:30 PM] gingerBill: I usually design the feature first then implement it.
[10:31 PM] ezysigh: (sorry, i didn't looka the videos... I kind of burned out of trying to parse everyones 1hr video presentations)
[10:32 PM] ezysigh: Any thoughts on the facilities? Rust macro-ish? Jai #run ish?
[10:37 PM] gingerBill: I thinking Nim-style "templates" or rust macros but I want them to be sane and act like a superset of procedure.
[10:38 PM] gingerBill: Jai #run was original thought of and I think it's a clever idea but it has huge fundamental problems which I discuss here: https://gist.github.com/gingerBill/98fe5117a7ba94437a0e7132eb25007f
[10:38 PM] gingerBill: Metaprogramming is a difficult tool to get just right.
[10:39 PM] gingerBill: I don't want something too complicated as it would defeat the point of the language. But I don't want none as that's too limiting.
[10:40 PM] gingerBill: I have introspection already and that's pretty useful already but that's a runtime facility (but I could extended some of the features to be compile time features).
[10:45 PM] ezysigh: If you're using some kind of VM to run the code, why can't you do ptr fixup when populating the .DATA section?
[10:46 PM] ezysigh: e.g. isn't this just the standard memdump serialization problem?
[10:46 PM] gingerBill: What about something like malloc()?
[10:46 PM] gingerBill: Or an external function pointer?
[10:46 PM] gingerBill: or memory mapped file?
[10:47 PM] gingerBill: How the fuck do you handle those edge cases?
[10:50 PM] ezysigh: I guess I'm assuming that you can't do everything compile time... that is, if you malloc() you're going to have to let the vm know where it is and how large it is if you want it to live to runtime. If you mmap(), forget it, unless you copy into some area you know is going to be preserved for runtime, similar for ext fnptr, if has to reify into a linker ref somehow.
[10:50 PM] gingerBill: Exactly my point.
[10:50 PM] gingerBill: It's a very powerful feature but extremely delicate.
[10:51 PM] ezysigh: I think you can make that line super explicit and get away with it. Like you can run an opengl application compiletime... but... unless your app tells the vm explicitly.. nothing gets saved for tunime
[10:51 PM] ezysigh: I believe that's basically what jai does
[10:52 PM] ezysigh: it's not like the opengl context refs live to runtime or something.
[10:52 PM] gingerBill: Thanks for a fucking briliant idea.
[10:53 PM] ezysigh: hey, no problem! :smiley:
[10:54 PM] gingerBill: A solution would be to be explicit about which global memory can saved from the CTE stage.
[10:54 PM] gingerBill: `#saved_cte var some_global int;`
[10:55 PM] gingerBill: However, this does mean some types would not be allowed e.g anything backed by a pointer internally.
[10:55 PM] ezysigh: well, if you know the layout, you can allow those too... you just have to know how to copy the memory associated with a type... if you know enough to move it and it's referents from one place to another, you know how to preserve it.
[10:56 PM] gingerBill: Not necessarily.
[10:56 PM] ezysigh: It's basically a serialization problem, is it not? I'm running this thing in one context (compiletime).. then I want to take the data in that context and transport it to a new context (runtime)
[10:57 PM] gingerBill: Partially. Somethings cannot be serialized.
[10:57 PM] gingerBill: And that's the problem.
[10:57 PM] ezysigh: and since the contexts have some intimate knowledge, you can take speedy shortcuts...
[10:59 PM] ezysigh: The fnptr problem, for example is just tracing the ptr to a root fn that gets turned into a linker ref (at worst), you know it's a fnptr..since you're the compiler :smiley:
[11:00 PM] gingerBill: The problem is that the calling convention in my compiler will have to act exactly like the C calling convention as those pointers could be passed to external programs.
[11:00 PM] gingerBill: e.g. C's qsort
[11:03 PM] gingerBill: I've thought about this problem extensively and it's a very difficult problem, indeed.