Bard is a small, high-level, general-purpose programming language.
It’s a Lisp.
It’s interactive, dynamic, and impurely functional. It’s designed to support changing a program interactively while it runs.
It provides support for concurrent and distributed programs, and encourages the use of immutable data.
The current work-in-progress version is 0.7. Its code is in an intermediate state of conversion from the Bard 0.3 implementation to simplify the surface language and support new language and runtime features.
After some extensive thinking, I’m currently redesigning Bard 0.7 along the following lines:
Earlier experiments have shown me that I can build the Bard object system using the CLOS MOP. I can also go the other way, but if I start with the MOP and build the Bard object system with it, then I have the MOP available to me, and it also makes it easy and convenient to build other object models. A nice example is the way that Clozure Common Lisp uses CLOS to seamlessly subsume the Objective-C object model on macOS.
Going the other way doesn’t have the same advantage. I can indeed start with the Bard object model and build something like the MOP with it, but the Bard object model doesn’t give me extra leverage for building and subsuming other object models the way that the MOP does.
It therefore makes sense to me to start with the MOP (or a slimmed down version of it like Closette or TinyCLOS), and build Bard on it.
I’m in the planning stages.