4 ms·
A fast Lisp interpreter in Dart
- suzuki 11y agoThis article is an English translation of http://www.oki-osk.jp/esc/dart/lisp.html http://www.oki-osk.jp/esc/dart/lisp.html which was introduced at https://news.ycombinator.com/item?id=9433114 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) >
- isoos 11y agoSounds an interesting project, I definitely will give it a try. I've just checked your other article: https://news.ycombinator.com/item?id=9670062 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...
- suzuki 11y agoZick Standard Lisp (https://github.com/zick/ZickStandardLisp 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 http://www.oki-osk.jp/esc/dart/lisp-en.html#6 were generated from it.
- Immortalin 11y agoAre you the writer of the article?
- erikb 11y agoAnybody 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)
- aidenn0 11y ago> 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).
- suzuki 11y agoThank 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.
- aidenn0 11y agoThanks 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.