Show me a lisp which is used by enough people to fill a conference in 2018 that isn't implemented in C. Show me a lisp machine which was manufactured any time in the past 10 years.
Steel Bank Common Lisp and Clozure Common Lisp are both implemented mostly in Lisp with some C code thrown in. And the European Lisp Symposium always has a large share of Common Lisp programmers.
CLOC tells me there's 28391 lines of C and 426525 lines of Lisp in there. Also remember that Lisp has, on average, higher code density than C thanks to advanced macro usage.
The runtime is written in C. That's the important bit. Just because the compiler, standard library, etc, isn't - doesn't mean it's not based on C. You cannot use SBCL without a C compiler.
The installation scripts are written in bash. That's the important bit. Just because the compiler, standard library, etc, isn't - doesn't mean it's not based on bash. You cannot use SBCL without a bash shell. /s
Of course you can use SBCL without a C compiler - you simply use a precompiled version. You can't build SBCL without a C compiler.
Shell scripts just slap commands together. You could just be a human interpreter reading the source and get the job done. C is a much more fundamental requirement of SBCL. Much more so than in the way SCBL depends on Python, for example (e.g. it doesn't).
Listen, I get that in the ivory tower of lisp you don't like looking at the little C bricks at the bottom, but the fact is that they exist and C is a hugely important language upon which the entire modern world of computing is built.
Sure, all of us execute stuff on kernels that are written in either C or C++ or C# or Objective-C, utilizing runtimes that are written in the same languages and calling APIs that are defined by the C application binary interface. That family of languages isn't going anywhere and choosing C instead of raw assembly is often chosen out of practical reasons, such as code maintainability.
Still, I find it hard to put an equality sign between "X has a runtime written in C" and "X is written in C".
The runtime for sbcl is just the garbage collector and parts of the OS interface. It's not like the JVM (or e.g. GNU clisp) where the runtime is interpreting code.
The OS interface for any program that is targeted at *nix is likely to be written at least partly in C, because POSIX is very hostile to non-C languages, which leaves us with the garbage collector.
If the GC's implementation language is the most important thing for an implementation then every language implemented mostly in C++, but using bdwgc for garbage collection is actually implemented in C and assembly.
This doesn't really sound sane to me. In this particular case, it would mean that if you throw away SBCL's compiler, SBCL's standard library, SBCL's extensions, and replace them with something completely different, you still get the same Lisp implementation because all of the aforementioned elements aren't a part of what you call the implementation.
The ones based on Java run on the JVM, which is always written in C :) The ones written in Lisp, well, at the bottom it's C again. I haven't seen a popular lisp yet with a meaningful amount of assembly in lieu of C.
I have some of these exotic Lisp Machines from the 80s which run no C code by default and where the C compiler is optional and written in Lisp. ;-) Obviously exotic and outdated. An alternate world.
> I haven't seen a popular lisp yet with a meaningful amount of assembly in lieu of C.
There are plenty to choose from, implement fully in Java like jikes, partially implemented in Java and C++ like OpenJDK, implemented in Java and C like MicroEJ, and lots of other ones to chose from.
Then there is project Metropolis on the OpenJDK, which targets to replace Hotspot with Graal, thus reducing the amount of C++ code on the runtime.
