4 ms·

A revised Lisp interpreter in Go

54 points by suzuki 11y ago

suzuki 11y ago
This is a revised port of Lisp interpreter in Dart http://www.oki-osk.jp/esc/dart/lisp-en.html http://www.oki-osk.jp/esc/dart/lisp-en.html Lisp interpreter in TypeScript http://www.oki-osk.jp/esc/typescript/lisp-en.html http://www.oki-osk.jp/esc/typescript/lisp-en.html to Go with the addition of "future" and "force" which makes use of goroutines' concurrency. (let ((a (future (prin1 "hi")))) (dotimes (i 20) (princ i) (princ " ")) (force a)) (terpri) It is not deterministic when the word "hi" will be printed. $ lisp-light test.l 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 "hi"16 17 18 19 $
- vmorgulis 11y ago
  Do you use a library for the multiprecision numbers?
  - suzuki 11y ago
    No, all numbers are represented by double precision floating point numbers (float64 in Go). The previous version (http://www.oki-osk.jp/esc/golang/lisp3.html http://www.oki-osk.jp/esc/golang/lisp3.html in Japanese) used Go's standard library "math/big" to represent big integers. However, the interpreter was also big and organized into several packages. I revised the interpreter smaller so that 1. it can be compiled in the easiest way, and 2. it may be comparable with the interpreter written in TypeScript. Note that TypeScript (i.e. JavaScript effectively) represents all numbers in float64. By the way, as for numbers only, the first interpreter (http://www.oki-osk.jp/esc/golang/lisp.html http://www.oki-osk.jp/esc/golang/lisp.html in Japanese) was the most powerful. It implemented mixed mode arithmetic including arbitrary-precision rational numbers with the "arith" package (http://www.oki-osk.jp/esc/golang/arith.html http://www.oki-osk.jp/esc/golang/arith.html in Japanese). However, the first interpreter was so tiny as a Lisp that it had no macros, while it was organized into several files.
- rastapasta42 11y ago
  Not sure if anyone is interested, but I'm currently writing a Lisp interpreter in Rust https://github.com/KostyaKow/RustyParenthesis https://github.com/KostyaKow/RustyParenthesis It's currently at very basic stage, but I have some basic things working, like map, filter, cons, car, cdr, define and lambda. Here's a small implementation of church numerals: https://github.com/KostyaKow/RustyParenthesis/blob/master/misc/church.lam https://github.com/KostyaKow/RustyParenthesis/blob/master/mi... And this is script that will eventually turn into standard library but so far it only contains map and filter https://github.com/KostyaKow/RustyParenthesis/blob/master/core.lam https://github.com/KostyaKow/RustyParenthesis/blob/master/co...
shitgoose 11y ago
at least is sounds better than kakapo: https://github.com/bytbox/kakapo https://github.com/bytbox/kakapo
amelius 11y ago
How does this compare performance-wise to a compiler?
- diskcat 11y ago
  I don't think people write lisp interpreters for performance reasons. It's more a computer science exercise which helps you understand languages better.
feylikurds 11y ago
Would not a JavaScript interpreter be more useful, especially considering the wider use of it?
- suzuki 11y ago
  It may be so. However, JavaScript (TypeScript) lacks concurrency and easy extendability with native codes.

54 points by suzuki 11y ago

This is a revised port of Lisp interpreter in Dart http://www.oki-osk.jp/esc/dart/lisp-en.html http://www.oki-osk.jp/esc/dart/lisp-en.html Lisp interpreter in TypeScript http://www.oki-osk.jp/esc/typescript/lisp-en.html http://www.oki-osk.jp/esc/typescript/lisp-en.html to Go with the addition of "future" and "force" which makes use of goroutines' concurrency. (let ((a (future (prin1 "hi")))) (dotimes (i 20) (princ i) (princ " ")) (force a)) (terpri) It is not deterministic when the word "hi" will be printed. $ lisp-light test.l 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 "hi"16 17 18 19 $

vmorgulis 11y ago
Do you use a library for the multiprecision numbers?
- suzuki 11y ago
  No, all numbers are represented by double precision floating point numbers (float64 in Go). The previous version (http://www.oki-osk.jp/esc/golang/lisp3.html http://www.oki-osk.jp/esc/golang/lisp3.html in Japanese) used Go's standard library "math/big" to represent big integers. However, the interpreter was also big and organized into several packages. I revised the interpreter smaller so that 1. it can be compiled in the easiest way, and 2. it may be comparable with the interpreter written in TypeScript. Note that TypeScript (i.e. JavaScript effectively) represents all numbers in float64. By the way, as for numbers only, the first interpreter (http://www.oki-osk.jp/esc/golang/lisp.html http://www.oki-osk.jp/esc/golang/lisp.html in Japanese) was the most powerful. It implemented mixed mode arithmetic including arbitrary-precision rational numbers with the "arith" package (http://www.oki-osk.jp/esc/golang/arith.html http://www.oki-osk.jp/esc/golang/arith.html in Japanese). However, the first interpreter was so tiny as a Lisp that it had no macros, while it was organized into several files.
rastapasta42 11y ago
Not sure if anyone is interested, but I'm currently writing a Lisp interpreter in Rust https://github.com/KostyaKow/RustyParenthesis https://github.com/KostyaKow/RustyParenthesis It's currently at very basic stage, but I have some basic things working, like map, filter, cons, car, cdr, define and lambda. Here's a small implementation of church numerals: https://github.com/KostyaKow/RustyParenthesis/blob/master/misc/church.lam https://github.com/KostyaKow/RustyParenthesis/blob/master/mi... And this is script that will eventually turn into standard library but so far it only contains map and filter https://github.com/KostyaKow/RustyParenthesis/blob/master/core.lam https://github.com/KostyaKow/RustyParenthesis/blob/master/co...

shitgoose 11y ago

at least is sounds better than kakapo: https://github.com/bytbox/kakapo https://github.com/bytbox/kakapo

amelius 11y ago

How does this compare performance-wise to a compiler?

diskcat 11y ago
I don't think people write lisp interpreters for performance reasons. It's more a computer science exercise which helps you understand languages better.

feylikurds 11y ago

Would not a JavaScript interpreter be more useful, especially considering the wider use of it?

suzuki 11y ago
It may be so. However, JavaScript (TypeScript) lacks concurrency and easy extendability with native codes.