Thoughts about a flexible yet compile-time turing complete language about basil HOT 2 CLOSED

Finally writing up a response to this...I think Basil's approach is fundamentally different to that which can be achieved in a super-low-level language like a Forth, but should ideally achieve the same ends. The main thing is that while small Forth-like languages can get away with sort of reductive semantics (a global unscoped dictionary for definitions is graceful but also doesn't scale great...), Basil is more targeted at users of existing languages and aims for high performance - this means, among other things, clear lexical scope and static type checking.

The solution Basil adopts to the above problems, of course, is simply to permit a highly dynamic "meta-language" confined to compile-time evaluation - we can do crazy things (albeit not really any more crazy than the average Lisp dialect...) and as long as we resolve them all in advance we shouldn't incur a runtime cost. As you mentioned, Basil already achieves point 1. (much more so in recent iterations than before, IMO) pretty decently, but by ensuring that no metaprogramming or dynamic code reaches the actual binary, performance should remain quite competitive - achieving point 2 (there's really no reason, besides compiler backend quality, why Basil couldn't compete with OCaml or even C++ in terms of generated code performance).

Point 3 is a little less explored in the current Basil iteration. In theory, the compile-time environment is turing-complete and quite powerful - it's essentially a Lisp interpreter, and with some caveats it supports a superset of Basil's runtime functionality. The issue with this is that Basil's current compile-time evaluation is quite slow, so to avoid overdoing compile-time evaluation we automatically lower any code that crosses a fairly small operation-count threshold. This is good for making sure we still compile expensive benchmarks, even if they aren't effectful, but it's kind of bad for sophisticated compile-time analyses and assertions. I think a good solution would simply be to allow "explicit comptime" blocks - this would be a built-in function that would evaluate its arguments without any compile-time profiling and auto-lowering. We could permit certain stateful and effectful functions, such as mutation and IO, at compile-time within such a block. With that, the user essentially has the full extent of the language's semantics available to express whatever ahead-of-time constraints or transformations they want. :)

Closing this since it doesn't really pertain to a particular feature. But we'll probably be exploring explicit compile-time blocks in the near future.

from basil.

But we'll probably be exploring explicit compile-time blocks in the near future.

That makes sense. But from my experience only if the blocks can apply to as small parts as one lexeme/token (any token at any place!). I.e. I tend to imagine the "block" as something enclosed in [ ] (as in Tcl, Til, etc.) or as just some prefix for an arbitrary lexeme/token. IDK.

from basil.