7 ms·

Kilo Lisp: A Kilo Byte-Sized Lisp System

140 points by KnuthIsGod 4y ago

dang 4y ago
Related: Kilo LISP - https://news.ycombinator.com/item?id=19415735 https://news.ycombinator.com/item?id=19415735 - March 2019 (48 comments)
- hackrnusr 4y ago
  Maybe also mention PicoLisp: https://picolisp.com/wiki/?home 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 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.
guerrilla 4y ago
That's yuuuuuge, try sectorlisp instead https://github.com/jart/sectorlisp https://github.com/jart/sectorlisp
- nils-m-holm 4y ago
  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_in_436_bytes/hpo00bq/?context=3 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/ 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.
  - guerrilla 4y ago
    Obviously...
rcarmo 4y ago
Neat, another one to add to my collection: https://taoofmac.com/space/dev/lisp https://taoofmac.com/space/dev/lisp (you can find most small LISPs there, reply here if you know more to add)
- sph 4y ago
  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 https://web.cs.wpi.edu/~jshutt/kernel.html
- jonathanstrange 4y ago
  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/ https://z3s5.com/ [2] https://github.com/nukata/lisp-in-go https://github.com/nukata/lisp-in-go
  - stevekemp 4y ago
    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 https://github.com/skx/yal
- medo-bear 4y ago
  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 https://github.com/CodyReichert/awesome-cl
  - rcarmo 4y ago
    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 https://taoofmac.com/static/graph
smcameron 4y ago
I bumped into this mini lisp thing the other day: https://github.com/yesco/minimalisp/blob/main/lisp.c 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.
- hnfong 4y ago
  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.hint https://github.com/ioccc-src/winner/blob/master/1989/jar.2.h... https://github.com/ioccc-src/winner/blob/master/1989/jar.2.c 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.
ForcedPush 4y ago
Can someone explain me why is Lisp still use today ?
- timbit42 4y ago
  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.
- eimrine 4y ago
  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?
  - ForcedPush 4y ago
    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.
    - euclaise 4y ago
      Old doesn't necessarily mean bad
    - medo-bear 4y ago
      for some people it is the optimum language to talk with the computer. also it allows you to go low, high, and meta level ;)
- rscho 4y ago
  Because it's a good concept? Broaden your horizon a bit, maybe?
- foobarbaz33 4y ago
  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.
PaulHoule 4y ago
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/ https://www.commanderx16.com/forum/index.php?/about-faq/
- timbit42 4y ago
  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.
- whartung 4y ago
  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.

140 points by KnuthIsGod 4y ago

dang 4y ago

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

hackrnusr 4y ago
Maybe also mention PicoLisp: https://picolisp.com/wiki/?home 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 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.

guerrilla 4y ago

That's yuuuuuge, try sectorlisp instead https://github.com/jart/sectorlisp https://github.com/jart/sectorlisp

nils-m-holm 4y ago
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_in_436_bytes/hpo00bq/?context=3 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/ 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.
- guerrilla 4y ago
  Obviously...

rcarmo 4y ago

Neat, another one to add to my collection: https://taoofmac.com/space/dev/lisp https://taoofmac.com/space/dev/lisp (you can find most small LISPs there, reply here if you know more to add)

sph 4y ago
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 https://web.cs.wpi.edu/~jshutt/kernel.html
jonathanstrange 4y ago
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/ https://z3s5.com/ [2] https://github.com/nukata/lisp-in-go https://github.com/nukata/lisp-in-go
- stevekemp 4y ago
  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 https://github.com/skx/yal
medo-bear 4y ago
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 https://github.com/CodyReichert/awesome-cl
- rcarmo 4y ago
  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 https://taoofmac.com/static/graph

smcameron 4y ago

I bumped into this mini lisp thing the other day: https://github.com/yesco/minimalisp/blob/main/lisp.c 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.

hnfong 4y ago
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.hint https://github.com/ioccc-src/winner/blob/master/1989/jar.2.h... https://github.com/ioccc-src/winner/blob/master/1989/jar.2.c 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.

ForcedPush 4y ago

Can someone explain me why is Lisp still use today ?

timbit42 4y ago
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.
eimrine 4y ago
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?
- ForcedPush 4y ago
  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.
  - euclaise 4y ago
    Old doesn't necessarily mean bad
  - medo-bear 4y ago
    for some people it is the optimum language to talk with the computer. also it allows you to go low, high, and meta level ;)
rscho 4y ago
Because it's a good concept? Broaden your horizon a bit, maybe?
foobarbaz33 4y ago
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.

PaulHoule 4y ago

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/ https://www.commanderx16.com/forum/index.php?/about-faq/

timbit42 4y ago
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.
whartung 4y ago
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.