Sic: Yet Another Mediocre Lisp Dialect in C++
The other day, I had an interesting realization about modern C++. One thing led to another and here I am with another Lisp dialect. Sorry about that.
Why?
It seemed like a good idea at the time.
What's it good for?
¯\_(ツ)_/¯
Also,
1. It's simple.
Most Lispish languages care about fripperies like efficiency and so will internally convert Lisp(ish) expressions to more efficient forms.
Not Sic. Here, it's still a list. If you prod at one with lldb,
you can chase the pointers. (Don't though; call function po on it
instead.) It stays Lispy all the way down.
2. It integrates nicely with C++
Everything in Sic is a plain old C++ type, so you can easily move between it and native code. In fact, this:
$(print, "2 + 2 =", $(add, 2, 2), "\n")
is a valid C++ expression that does what you'd expect (if you've
imported the sic namespace). So it's easy to integrate it into a
C++ program.
3. No external files needed
Unlike most Lispish language, there is no external library; all functions are written in C++.
4. You can horrify Lisp purists with it.
$(print, "C++ is an acceptable Lisp!\n")
What's wrong with it?
- There's a lot of powerful Lisp(ish) functionality that isn't written yet.
- There's no garbage collection. It just leaks memory.
Compiling
On a sufficiently Unix-like operating system with Clang installed, just
cd src
make
If you want to use gcc instead, edit the Makefile first.
Note that this needs a recent compiler, one that supports C++17.
This will produce both an executable interpreter (sic) and a library
(libsic.a).
Documentation
The reference manual is generated during building but there's a courtesy copy here.
I also did a blog post about it here.
License
This is Free/Open-source software released under the terms of the wxWidgets license (i.e. the GNU LGPL but with less restrictions on binary distribution.)
See Copyright.txt for details.