In a similar vein, Elixir has what is basically compile-time-only macros (the macros being conceptually similar to Scheme's). You can transform the AST to arbitrary other AST, with hygiene, and of course, provides ways to reference the parent scope if needed. Macros are even based on the familiar quote and unquote system of lisp/scheme.
Caveat: I will note that technically speaking Elixir does not have a strictly separate compile time and runtime. However, in practice the language is used like it does. Compile time code is normally just a bunch of definitions of modules and macros and functions contained within. Executing the compile time code normally has no effect other than creating compiled modules. One can technically put things like loops or I/O etc at the top level, but that is normally only done if writing "scripts", rather than normal progarm code.
Thus for a normal program compiling it is basically just running an interpreter over the source code of the program. Indeed the elixir compiler executable is literally just the same as the interpreter used for scripts except with a flag to save compiled modules to disk rather than just leaving them in memory. (Plus a few other really minor differences that are not really relevant here.)
Runtime is then just asking the beam VM to execute the some function in the previously compiled module. While in theory one could try to define additional modules at runtime, this is not normally done. The language design strongly discourages this. If you need to generate modules programmatically, you are better off doing it as macros, which will run at compile time. Thus, normally the compiler is not used at runtime, and while I don't think elixir offers an option to remove the compiler at runtime, one could remove the underlying Erlang compiler at runtime, and without that the elixir compiler would just fail.
There are, of course, no artificial limitations in macros. They can run any code that could be run at runtime, in addition to modifying the AST, or defining new modules. In theory the macros could even present an interactive user interface, but obviously that would be absurd.
Caveat: I will note that technically speaking Elixir does not have a strictly separate compile time and runtime. However, in practice the language is used like it does. Compile time code is normally just a bunch of definitions of modules and macros and functions contained within. Executing the compile time code normally has no effect other than creating compiled modules. One can technically put things like loops or I/O etc at the top level, but that is normally only done if writing "scripts", rather than normal progarm code.
Thus for a normal program compiling it is basically just running an interpreter over the source code of the program. Indeed the elixir compiler executable is literally just the same as the interpreter used for scripts except with a flag to save compiled modules to disk rather than just leaving them in memory. (Plus a few other really minor differences that are not really relevant here.)
Runtime is then just asking the beam VM to execute the some function in the previously compiled module. While in theory one could try to define additional modules at runtime, this is not normally done. The language design strongly discourages this. If you need to generate modules programmatically, you are better off doing it as macros, which will run at compile time. Thus, normally the compiler is not used at runtime, and while I don't think elixir offers an option to remove the compiler at runtime, one could remove the underlying Erlang compiler at runtime, and without that the elixir compiler would just fail.
There are, of course, no artificial limitations in macros. They can run any code that could be run at runtime, in addition to modifying the AST, or defining new modules. In theory the macros could even present an interactive user interface, but obviously that would be absurd.