Here are some things we might work on in future versions of Fennel.
None of this should be interpreted as a commitment to land a specific feature, just a list of possibilities.
There are some places the compiler emits immediately-invoked function expressions out of an abundance of caution which aren't strictly necessary.
Should be able to do analysis without a plugin; just dump the data for a given compilation run. But what data? Is the scope table enough?
Prototype: https://git.sr.ht/~technomancy/fennel/log/analysis
Can we remove all "calls" from patterns and make them look like pure data?
Discussion: https://lists.sr.ht/~technomancy/fennel/%3C87fs3c44ry.fsf%40hagelb.org%3E
Currently it's very difficult to ship a single-file library that can be used as a runtime module but also contains macros.
Discussion: https://lists.sr.ht/~technomancy/fennel/%3C87y1huumlm.fsf%40gmail.com%3E
This is a conspicuous absence from Lua which causes a lot of problems; we should come up and document with a way to require both runtime modules and macro modules in a way that allows the whole directory to be relocated.
The --compile-binary command currently embeds your Fennel program as
a byte array of source in a C file before compiling that to a
binary. It would be more efficient to compile it to bytecode and embed
the bytecode in the C source.
We could use a couple more macros to make programmatic interaction with metadata better.
We might also consider moving AST metadata to use the same system; the current system is a bit of a mishmash since lists and non-list tables are treated differently.
The hooks system in the compiler is currently somewhat ad-hoc.
See the compiler plugin hooks page.
The sandbox used for macros is currently all-or-nothing. If you want access to the filesystem within a macro module, then you need to disable the macro sandbox entirely. This is not ideal; we should allow you to specify that a given macro should have access to a given directory, etc.
See the require-field page.
See the parser macros page.