
A revised Lisp interpreter in Go - suzuki
http://www.oki-osk.jp/esc/golang/lisp4-en.html
======
suzuki
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
Do you use a library for the multiprecision numbers?

~~~
suzuki
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.

------
amelius
How does this compare performance-wise to a compiler?

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

------
shitgoose
at least is sounds better than kakapo:

[https://github.com/bytbox/kakapo](https://github.com/bytbox/kakapo)

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

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

