Rough notes of external compilers idea

zig!

dedicated directory (could do something similar for Rust) seems like C, C++, Zig supported in simulator, compile on first occurrence? what if files changed? gather all files... in build, up front

if we allow inline code want to know which files track a "changed" list, after first time? search for some sigil (could use _CAPS Lua restriction?) replace with symbol lookup (internally generated) original string as long comment? prepend -- if already in long string form else enclose " " or ' ' ones in same (check for matching parenthesis?) could possibly be actual token for proper results... have an effect on linters etc?

_INLINE("zig"[, ???], [[ CODE! ]], ...)

where ??? is some sort of namespace resolution

or could do

_INLINE(OBJECT, [[ CODE! ]], ...)

Not sure of a good way to do arguments

 where OBJECT is result of require() and must be some kind of "namespace", that also specifies "zig"

On success these would be transplanted to library

expose /Corona folder and use same lib???

looks like lhf's token stuff is a starting point

really just want to check for (in above case) "_INLINE" name... ensure "(" and ")" around it, expected to contain string (or concat of strings?) simple string okay, too

possibly better alternative would be, say, _INLINE_ZIG(...), _INLINE_C(...), _INLINE_RUST(...)

in C case, might be able to use, say, https://github.com/q66/cffi-lua (sounds like libffi itself support iOS) used these sorts of libffi changes: https://github.com/libffi/libffi/pull/535 had to add tramp C file to settings LUA_BUILDING for static build, checking that or LUA_BUILDING_DLL for definition of FFI_API used extern "C" rather than <lua.hpp> required and commented out definitions of new / delete operators x86 build changes

anyhow, would gather that string, add it to a new file and export a function (with signature...), do the lookup, then replace with that

in build could all go in one DLL
in regular use, would have to know all files...
  could do search and preprocess, OR make per-snippet DLL...
    probably a hybrid, say first case would do the search, then keep list
    potentially different strategies if relaunching when files changed
				
require() ->
  lua_CFunction one...
  known signatures
  others could be available for FFI
  should park non-lua_CFunction one in shared library that outlives Lua state