A fast Lisp interpreter in Dart | Hacker News Reader

A fast Lisp interpreter in Dart

oki-osk.jp

64 pointssuzuki10 comments

This article is an English translation of http://www.oki-osk.jp/esc/dart/lisp.html which was introduced at https://news.ycombinator.com/item?id=9433114 as "Lisp in 1,200 lines of Dart."

  $ curl -R -O http://www.oki-osk.jp/esc/dart/lisp/lisp-27-05-08.tar.bz2
  $ tar xf lisp-27-05-08.tar.bz2
  $ cd lisp-27-05-08
  $ dart lisp.dart
  > (dump)
  (dotimes dolist while nconc last nreverse _nreverse assoc assq member memq listp
   or mapcar and append _append letrec let when if equal /= <= >= > setcdr setcar 
  null = identity print consp not cdddr cddar cdadr cdaar caddr cadar caadr caaar 
  cddr cdar cadr caar defun defmacro *version* dump exit apply symbol-name intern 
  make-symbol gensym *gensym-counter* terpri princ prin1 truncate / - * + mod % < 
  eql numberp stringp length rplacd rplaca list eq atom cons cdr car)
  >

Sounds an interesting project, I definitely will give it a try. I've just checked your other article: https://news.ycombinator.com/item?id=9670062

Is there a benchmark suite that could compare various Lisp implementations? Would be interesting to see their overall comparison...

Zick Standard Lisp (https://github.com/zick/ZickStandardLisp) by "Zick" serves as a handy benchmark generator. The second round benchmark and the final round benchmark used in http://www.oki-osk.jp/esc/dart/lisp-en.html#6 were generated from it.

Are you the writer of the article?

> Nevertheless, this defect is largely harmless because Common Lisp separates the name space into one for functions and one for variables. In other words, it can be said that the existence of this defect has been justified the separation of name spaces which has made the semantics of the Common Lisp language complex unnecessarily

One note on variable capture in Common Lisp; while it is true that a lisp-2 runs into the issues somewhat less often than a lisp-1, the existence of FLET and LABELS should let people know that it doesn't solve the problem.

The real solution to this in Common Lisp is packages.

  (in-package foo)
  
  (defun bar () (do-something))
  (defmacro baz (x) `(bar ,x))

  (in-package quux)
  (flet ((bar () (do-something-else)))
    (baz 2))                           ; calls foo::bar not the bar bound in above FLET

Also, many people like that Common Lisp has two namespaces because there are many identifiers that are useful as both nouns and verbs (e.g. LIST).

Thank you for your comment. However, a capture still occurs if a local variable happens to have the same name as some function in the standard library.

As for nouns and verbs, higher-order functions treat verbs (i.e. functions) as values (i.e. nouns). From the viewpoint of functional programming or lambda calculus, the distinction between them is not necessarily natural.

Thanks for replying! It is true that there is capture w.r.t. the standard library, and the Common Lisp specification forbids rebinding those. This is a case where the separate namespace complicates the semantics.

Anybody know that game where you write a program that can print itself? Are there games where a program interprets code from another language so well it can interpret an interpreter that can interpret its code? (interpreterA is written in langA, it can run interpreterB written in langB, which is able to run enough of langA to run interpreterA)

https://github.com/mame/quine-relay

100 language cyclic quine relay.

If I find it again, there's a video of a quine deduced by a scheme interpreter relationally defined in minikanren.

Reply on news.ycombinator.com