Very neat! I had not looked into Bel before, but I feel like I need to now. Some aspects of it look pretty close to John Shutt's Kernel language, where the core construct is Vau instead of Lambda, and creates something quite like the mac macro construct described for Bel, receiving its arguments unevaluated along with an optional parameter which is the calling environment, I think like the described "scope" variable. It also provides wrap/unwrap functions which wrap a Vau in a layer of parameter-evaluation, so a normal lambda would look like (wrap (vau #unused_env (parameters..) body...) and macros and functions (and builtins like if, lambda, etc!) all unify into one concept which he calls combiners.
It's cool to see some convergent evolution vaguely towards this direction, I think it's very beautiful. I also agree, I think a language like this that's purely functional would be a great boon and make these advanced features easier to reason about! I've been working on something similar I'll share when it actually works - looks like there are dozens of us!
Bel's macros are definitely macros and not Kernel-style operatives. Here is a comparison, for clarity:
(A) Bel's macros do a syntax->syntax transformation, but this expansion happens (according to the spec) in the evaluator, after concluding that the operator is a macro and not a function.
(B) In the greater Lisp-and-Scheme tradition, macros do a syntax->syntax transformation, but at compile time. (Usually after "read" but before "eval".) In this sense, they are small compilers themselves. (This puts limitations on macros: they have to be "statically visible" in the code. You can't late-compute a macro at runtime in this system.)
(C) Kernel's operatives do a syntax->"side effect" transformation, at that same late stage as Bel's macros. Kernel operatives are essentially functions, except that the evaluation of the operands (syntax) into arguments (values) has been suppressed. In this sense, operatives are small interpreters.
If an (A) macro is well-behaved, you can often "optimize" it either to a (B) form or a (C) form. In my Bel implementation, it took me ages to notice that I could do the latter. I documented it here: https://github.com/masak/alma/issues/302#issuecomment-992556...
As someone who is on their third year of Bel implementation -- getting there -- I recognize many of the insights in this post about continuations and about the well-chosen Bel built-ins. Great work, and thanks for writing this post.
It's cool to see some convergent evolution vaguely towards this direction, I think it's very beautiful. I also agree, I think a language like this that's purely functional would be a great boon and make these advanced features easier to reason about! I've been working on something similar I'll share when it actually works - looks like there are dozens of us!