[_samt_]

loadfile() isn't implemented in clx, and neither are the other dynamic code-loading features. Supporting them would require runtime code interpretation, which doesn't fit clx's current AOT model.

Could that change one day? Maybe, but it's not a priority right now.

[emj]

I looked at your goals and Load is clearly out of scope. I think the question here is could you load your AOT compiled and executable code like we do with Lua scripts only give the compiled code access to a safe Lua env. i.e. Not giving it access to all symbols.

[_samt_]

That's an interesting idea.

Loading precompiled CLX modules is a different problem though. In theory, a native module could be loaded and executed with a restricted environment, similar to how Lua modules receive a specific `_ENV`.

It's not something CLX supports today, but it's much closer to the project's goals than runtime compilation of Lua source code.

One challenge is that standard Lua does not provide a way to change a function's `_ENV` after compilation (unlike the old `setfenv/getfenv` mechanism from Lua 5.1).

I've been considering adding environment manipulation capabilities to the CLX C++ API (while keeping Lua compatibility intact). If that happens, loading CLX modules into custom environments could become relatively straightforward.

[vrighter]

so a kind of setfenv type thing, but only from c++. That could work

[_samt_]

Yes that's it