Arc, a LISP written in Racket LISP [2] by Paul Graham
Several (tiny) LISP and Scheme implementations [5]
Alan Kay wrote and lectured many times about the LISP eval implementation in itself on page 13 of the LISP 1.5 Manual [6] as the "Maxwells equations of software" [3]
There is an derivation of this idea, a Smalltalk eval written in itself, see chapter IV and Smalltalk 71 [4].
My Z3S5 Lisp[1] is rather big, it's intended to integrate well into Go programs, but it's based on the 1-page Nukata Lisp[2]. Go creates much larger binaries than C, though.
It looks like your lisp has a lot of built-in/primitives, I'll have to explore!
I also wrote a simple lisp in go, in my case I added LSP support for completion and help-on-hover, which was a fun addition I've not seen in anything else.
you have some things there that i didn't know about, which is pretty cool. however, i think you need to put more work into this. sicl, clozure, armed bear are common lisp implementations. you also left out some pretty big ones - sbcl and ecl. for more common lisp libraries see https://github.com/CodyReichert/awesome-cl
I appreciate SectorLISP, but it is in a completely different ballpark. Last time I checked (and this is a while ago), it was dynamically scoped and not tail-recursive, i.e. programs will overflow the stack when running long enough. See this discussion on Reddit for details:
Unfortunately the discussion ended suddenly back then.
The long story is: you cannot have tail recursion and dynamic scoping without running into all kinds of funny issues related to the upward and downward FUNARG problem. This is discussed in detail in my book, LISP From Nothing (http://t3x.org/lfn/)
Without tail recursion in the core of the implementation (in the case of SectorLISP in the assembly language part), you cannot have it in the high-level part (LISP in LISP), either, because the interpreter interpreting the LISP in LISP will eventually overflow the stack.
Surprisingly the folks behind Clojure were never able to fill this gap despite the Android SDK being based on Java.
One of my long-term goals is to create an analog of AutoHotkey for Android. Tasker is problematic on several levels (poor code quality, single developer syndrome, closed source, ...) and it would be nice for a change to write scripts, instead of fiddle around with Tasker's poorly laid out GUI, to automate Android apps in a REPL environment through directly interacting with the Android Accessibility API.
I think the single largest barrier to a well running compact Lisp is simply memory.
The more often you run out of heap, the more often you have to GC, and that memory churn on those very slow CPUs has great impact.
FORTH doesn't have this problem because it's quite static. It "never" reuses memory, the dictionary (where all the code and data live) just gets larger. When it gets too big, you restart/reset the dictionary (via FORGET), and memory reclamation is a simple pointer change.
BASIC only has the memory issue at runtime, specifically with Strings and the heap they're stored on. Everything else is quite static. When you type "RUN", the pointers to the working memory are reset and the variable tables et al are rebuilt as the the program is run.
Since BASIC separates the code from the data, this is easy. FORTH intermixes the code with the data, but since it doesn't reuse any of it, that works quite efficiently.
Lisps tend to mix code and data and that make heap fragmentation a real issue. Slow CPUs make for slow GC.
But, give more memory, GC happens less. When it happens, it's "more", it's "harder", but that can be more acceptable if the user is prepared for it. As I understand it, even the Lisp machines would get into states where it was simply faster to restart than have a "full" GC run.
Memory and MHz makes Lisps much happier. The Commander can have a lot of memory, but it's all in banks. A Lisp, perhaps, could be written that leverages that seamlessly, but it's not free. Not like with, say, a 65816 or the x86 where the banking (segmenting) is part and parcel to the addressing and instruction set vs being bolted on to something like a 6502.
Obviously one can write Lisp that CONSes less, but it's not especially idiomatic.
We did have one. It was called Logo. If you ignore the turtle graphics, underneath was a lisp with fixed arity so parens were optional. Unfortunately, most people wrote it off as a child's toy language because of the turtle graphics.
To this day nothing else beats the fast feedback loop of Common lisp. It has the best hot-reload abilities of any other language.
Other languages tout fast build times (that actually are not that fast) completely unaware they are stuck in slow feedback loops.
Wait until you deal with slow loading process that is independant of your language. (ie even infinitly fast build time wont' save you). Once that data is loaded into your data structure you want it to STAY there. Lisp wills save your butt allowing you to continue to develop with the tight feedback loop.
"So the problem is—I’ve said this about both Smalltalk and Lisp—they tend to eat their young. What I mean is that both Lisp and Smalltalk are really fabulous vehicles, because they have a meta-system. They have so many ways of dealing with problems that the early-binding languages don’t have, that it’s very, very difficult for people who like Lisp or Smalltalk to imagine anything else." -Alan Kay
Well, okay, to be fair the real reason is probably because Common Lisp is very mature, well specified, has a lot of useful libraries (Quicklisp is great), and several implementations can produce very efficient and fast code (about as fast as GC code can be, especially if you make good use of facilities like dynamic-extent).
Because it is a family of languages that are perceived by many as being aesthetically pleasing, and offer a lot of features that give you a very different perspective on programming from the typical C-derived languages. Lisp is just fun to work with.
Also the sense of tradition can be appealing - it is the second-oldest language still in use, after FORTRAN, and has been incredibly formative in many respects. It‘s similar to how learning Latin doesn’t only allow you to read a lot of great works of the past, but also helps you understand modern languages.
Such anger for this question. One good answer (so far) and two unhelpfuls. It’s a good question perhaps asked badly. So I’ll take the liberty of rephrasing. Why learn lisp today instead of haskell, rust, kotlin, or any of the myriad other languages on offer?
As someone coming from Haskell and learning Common Lisp, I can say that Lisp just feels mature. It feels well thought out and logical. I can read the entire HyperSpec and it makes sense and it’s precise and there’s not a pile of language extensions. Haskell has inner beauty but the huge warts of something that is newer and more experimental.
Partially as a result of all this, Lisp has other things that Haskell lacks, such as good editor support and a great REPL. Haskell editor tooling is awful and although it has a REPL it’s nowhere near as good as Common Lisp’s.
yeah as a haskeller, there is a LOT that I wish haskell had that was better... if it had taken more of the good ideas from common lisp early on in its evolution, would be in a much better place.
I'm looking forward to a replacement; Unison might be it, a lot of its choices are better oriented towards interactive development, but the jury is still out on this. Other candidates imo are lean, agda, roc, verse (this one I heavily doubt), or ghc fixing itself so this discussion is unnecessary. But there is space for a language that cuts out the historical baggage. For a while, I hoped that would be purescript, but I think that unlikely at this point.
The way it’s phrased can be read as having the implication “Other things are newer or more popular, so why bother?” That may not have been your intent, but this is how it can come across, especially when people have been insincerely asking this question for decades in order to troll or poke fun.
Lisp is biding its time as all other languages slowly evolve into Lisps. Eventually, they will all merge and there will be one language and it will be Lisp.
You are on the website written on Lisp and on the best news source about Lisp and one of admins is the author of one of Lisp dialects and you asking that shit about Lisp here? Why?
I mean... Was not a rhetorical question, I saw more than one thing about Lisp this week and when searching about it, I saw it was an old language. Really just curious about it.
(you can find most small LISPs there, reply here if you know more to add)