Learn more

lispy-format 1.0


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.

Here is an old preview.

I've already achieved significant progress on a private branch.

After a surprisingly long and torturous path,
I can finally resume work on this!

(I made the Epic FORMAT table years ago as a precursor to this work.)

LOOP/Iterate/mapcar/dolist etc replacement


loop is not great, iterate is a bit better but shares its monolithic nature, and the alternatives like mapcar are not really powerful and flexible enough.


This library will implement a revolutionary new paradigm for iteration and mapping. It is extremely simple, intuitive, modular, flexible, powerful and optimizable, and easily scales from trivial use-cases to very complex, so you can just use it always. It will basically obsolete every iteration and mapping construct you know of, and then some.

This is a spiritual successor to my various Loopless projects that I worked on for years and deleted relatively recently, and other related work such as multiple-value mapping. I completely stopped using loop eons ago and now make heavy use of mapcar and friends, but this is not enough and after several iterations of failed attempts at LOOP replacement, I finally came up with a truly revolutionary paradigm shift in computer science (or at least, a very big evolutionary leap). This is actually just a different arrangement of already existing concepts such as iterators, but designed and integrated in a much more flexible and powerful way without sacrificing performance (and in fact, improving it).

I already know what the project will be called, but I'm keeping it a secret until a first release.

I already know exactly what the high-level syntax and semantics will be. I could trivially tell you what it is, but I want to keep all the glory for myself on this one. ;P (It took me quite a bit of really hard work to reach that point, and if I immediately revealed the fruits of my labor then someone could implement a crude version and reap all the glory before I have perfected the entirety of the design at all layers of abstraction.) The high-level syntax and semantics is actually just an embarrassingly simple variation on one of the standard Common Lisp constructs.

As for the mid-level and low-level semantics, I have some good ideas about it, but much work yet remains to be done. I recently became an expert in an area of the MOP that I believe will be absolutely crucial to the mid-level and low-level semantics.

I have already spent several months designing this on graph paper. I am now ready to try actually implementing this (once I'm done with the above work items).