Kilo Lisp: A Kilo Byte-Sized Lisp System | Hacker News Reader

Kilo Lisp: A Kilo Byte-Sized Lisp System

t3x.org

140 pointsKnuthIsGod39 comments

Neat, another one to add to my collection: https://taoofmac.com/space/dev/lisp

(you can find most small LISPs there, reply here if you know more to add)

Beautiful, thanks. I'm writing my own small interpreter and it's good to have a reference of all other implementations to steal/get inspired from.

Also, looks like you're missing Kernel: https://web.cs.wpi.edu/~jshutt/kernel.html

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.

[1] https://z3s5.com/ [2] https://github.com/nukata/lisp-in-go

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.

https://github.com/skx/yal

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

Well, I do have 8000 pages of content, it's hard to update the whole thing... Plus I don't use Steel Bank anymore, so that's likely why I left it out.

But I'm adding all the stuff mentioned, thanks!

https://taoofmac.com/static/graph

owl lisp: https://gitlab.com/owl-lisp/owl - https://haltp.org/posts/owl.html - talk: https://www.youtube.com/watch?v=utOVF0U7Zd8

otus lisp: https://github.com/yuriy-chumak/ol - owl lisp with ffi - http://yuriy-chumak.github.io/ol/

owl can compile to c or interpret - otus is a small interpreter 45kb

Just found one after replying to another comment on this story.

https://github.com/ioccc-src/winner/blob/master/1989/jar.2.c (accompanying explanation: https://github.com/ioccc-src/winner/blob/master/1989/jar.2.h... )

It apparently works somewhat after a few minor tweaks.

Another one that I've bookmarked some months earlier: https://github.com/rui314/minilisp

I went to look for uLisp, which is there and I am quite fond of, but “for Arduino” may have only been its original intent. It’s a bit broader now.

> Lisp for Arduino, Adafruit M0/M4, Micro:bit, ESP8266/32, RISC-V, and Teensy 4.x boards.

And even that needs updated on the site, as it runs on the RP2040 (Pi Pico) as well, with wireless functions on the W variant, even.

Bel, a LISP written in itself [1] by Paul Graham.

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].

[1] http://www.paulgraham.com/bel.html

[2] http://www.paulgraham.com/arc.html

[3a] https://github.com/informatimago/lisp-1-5/blob/master/LISP-1...

[3b] https://queue.acm.org/detail.cfm?id=1039523

[3c] https://michaelnielsen.org/ddi/lisp-as-the-maxwells-equation...

[4] http://worrydream.com/EarlyHistoryOfSmalltalk/

[5] http://www.iro.umontreal.ca/~feeley/

[6] https://michaelnielsen.org/ddi/wp-content/uploads/2012/04/Li...

That's yuuuuuge, try sectorlisp instead

https://github.com/jart/sectorlisp

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:

https://old.reddit.com/r/lisp/comments/rkxh3v/lisp_with_gc_i...

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.

KiloLISP is lexically scoped and tail-recursive.

Obviously...

I bumped into this mini lisp thing the other day:

https://github.com/yesco/minimalisp/blob/main/lisp.c

It's not finished yet, but the coding style and tricks going on in it are wild.

It looked like it could have been an IOCCC entry. But then, I thought, wouldn't that be cliché? Somebody must have done this years ago.

Turns out that's exactly what's happened: https://github.com/ioccc-src/winner/blob/master/1989/jar.2.h... https://github.com/ioccc-src/winner/blob/master/1989/jar.2.c

PS: I was able to get it to compile after a few minor tweaks. Impressive stuff.

Kilo LISP - https://news.ycombinator.com/item?id=19415735 - March 2019 (48 comments)

Maybe also mention PicoLisp:

https://picolisp.com/wiki/?home

... in part because of this interesting alternative to Android Studio for interacting with the Android SDK through a LISP REPL:

https://picolisp.com/wiki/?PilBox

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 definitely wonder if we could have had a good compact lisp for 8 bit machines instead of BASIC and FORTH.

Might be nice to see one for

https://www.commanderx16.com/forum/index.php?/about-faq/

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.

Can someone explain me why is Lisp still use today ?

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.

Old doesn't necessarily mean bad

for some people it is the optimum language to talk with the computer. also it allows you to go low, high, and meta level ;)

Because it's a good concept? Broaden your horizon a bit, maybe?

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.

> To this day nothing else beats the fast feedback loop of Common lisp.

JS + devtools...

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?

I like this explanation: https://gigamonkeys.com/book/introduction-why-lisp.html

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.

I don't know that its good to learn it instead of any of those, but its fantastic to learn in addition to.

It's just different. I love haskell, but also love lisp. For very different reasons, but they're both delightful expressions of thought.

I saw my question bother more than one person. I was really just trying to understand.

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.

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.

S-expressions are the nicest syntax.

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 LISP and Smalltalk are still the best programming languages ever made? [1]

A dialect Scheme was used in the famous MIT lecture course [2], the video [3] and book[4].

Many computer scientist grew up with thinking in LISP.

[1] https://queue.acm.org/detail.cfm?id=1039523

"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

[2] https://en.wikipedia.org/wiki/Structure_and_Interpretation_o...

[3] https://ocw.mit.edu/courses/6-001-structure-and-interpretati...

[4] http://mitpress.mit.edu/sicp

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.

Reply on news.ycombinator.com