Roadmap
Please sponsor me to speed up development of these exciting features!
- 🛈 Background
- 🗲 Why I'm excited
- ✍ Current status
⚓
Lambda lists being one of the most omnipresent features in Common Lisp, obviously it would be incredibly useful to be able to manipulate them easily.
Very few projects even try to tackle this problem, and none of them make a good job of it or are enjoyable to use.
first-class-lambda-lists will provide a simple unified extensible way of processing lambda lists.
It will make it very easy to add support for new lambda list keywords and lambda list types.
A system for easily converting higher-level lambda lists to their lower-level equivalents is also planned.
The project is in a relatively advanced state of completion, but is not yet usable and is a sprawling mess. I am looking to make major refactorings and simplifications. This will be my most complex library yet.
⚓
There are a billion Common Lisp unit testing frameworks, none of which I find appealing. (Ok, honestly I don't even want to check, as clearly none of them could possibly appeal to my very specific tastes by chance.)
I have been using Parachute,
but I'm confident I can make something I like much better.
I will make a unit testing framework leveraging definitions-systems for extreme simplicity and extensibility. With 30+ ready-to-use libraries, I already have plenty of incentive to make a great unit testing framework for myself, even if nobody else used it.
The focus of the initial version will be to be good enough for me, but I hope to eventually make it the best Common Lisp unit testing framework, though it could take years. The first version could theoretically already be the best Common Lisp unit testing framework, but given that I won't even review the capabilities of the other existing unit testing frameworks, this seems highly unlikely.
Ideally, eventually I would take the time to do such a review and improve my unit testing framework until it's effectively a conceptual superset of all the other unit testing frameworks, at least with respect to their intrinsically desirable features.
I usually try to make a "best of breed" library with the first release, but I believe this would represent way too much work in this case, and would push back other very important projects like lispy-format 1.0 way too much. Maybe I'll just give up and review the other libraries before making my own after all, but no promises...
I have not started yet. I need to finish first-class-lambda-lists first.
⚓
There is no fun way to process declarations.
parse-declarations looks pretty boring to me.
I'll make a fun way to process declarations that will leverage definitions-systems.
I made 2 failed attempts in the past. Third time's the charm?
⚓
As far as I'm concerned, metabang-bind has a good core concept, but takes the wrong design decisions at nearly every turn.
explicit-bind is a great metabang-bind replacement project I have been trying to finish since forever.
Stalled on first-class-lambda-lists and declarations processing.
⚓
format is a disgrace, a black mark on Common Lisp. Packing a complex control language into a string is deeply insane when we could and should just use s-expressions. format is the single worst-designed feature in Common Lisp, even worse than loop. format is not extensible, despite the very constrained ~/~/ escape hatch.
It is simply mind-boggling that format is still used and largely embraced by the community in 2020.
lispy-format 1.0 properly translates the essence of format into a proper s-expressions form. A guaranteed smash hit!
I know exactly what the final product will look like. There are 2 levels: individual functions which can be used standalone or in concert, and a macro for concisely and efficiently combining multiple output operations in one go.
lispy-format 1.0 will be far more readable than format, and it will be completely modular and extensible. And of course, it properly uses the package system, so you can easily write your own extended version of the standard built-in operators if you like, or design your own features which will seamlessly integrate with built-in features and third-party features.
One of several advantages of lispy-format 1.0 is that a command's arguments are specified with the command instead of all commands being specified ahead of time and then all arguments, making it hard to correlate commands with their arguments.
lispy-format 1.0 will be very easy to learn, regardless of the user's level of proficiency with format. That said, format experts will find many familiar similarities compared to format, making transition easy. Tools should eventually be provided to help migration.
I've already achieved significant progress on a private branch.
After a surprisingly long and torturous path, I finally resumed work on this, but quickly hit a snag which resulted in a reshuffling and expansion of my roadmap, so this has been pushed back again, sorry.
(I made the Epic FORMAT table years ago as a precursor to this work.)