Live data from Hacker News

(How to Write a (Lisp) Interpreter (In Python)) (2010)

norvig.com

71–80 of 101 posts

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#71

What I find promising about LISP is the ability to do term rewriting and macros. But people write lisps in imperative style rather than definitions of desired behaviour declaratively. I don't think we've sufficiently solved how to define desired behaviour to a computer. Term rewriting behaviours. What are your thoughts? I started trying to implement term rewriting into my LISP parser, which is the idea that we can ma…

StackOverflow answer [January 2024], using term rewriting:

https://stackoverflow.com/a/77857873/1250772

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#72
post #42
post #20

Earlier quoted context omitted.

Lisp is not the language for that unfortunately, it is very much an imperative language with better syntax and _some_ macros. Scheme is close but quotation isn't thought about nearly enough. It is generally a CS problem as logic systems with quotation are very much an open problem. I think that types have gotten too much attention and quotation way too little. Macros are basically a way to deal with the fact that nei…

I think a lot of confusion come from the fact that a lot of people (including, presumably, the parent) use "Lisp" to mean Common Lisp, whereas many others take it to mean what Common Lisp people might call "lisp" or lisp-family. You can easily have a substanceless argument this way, and many often do!

There is no member of the lisp family that treats quotation as a first class citizen of the language. Granted, lisp is one of the few language families where it's even a part of the language but it's at best an afterthought, which is why you need macros to manipulate unquoted expressions.

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#73
post #55

Earlier quoted context omitted.

Lisp is eldritch by programming language standards; we are still wrestling with the ramifications of McCarthy's half-page of code.

You think lisp is "weird and sinister or ghostly" and that 'we' are still wrestling with something 66 years later? This sounds more like someone getting caught up in the pageantry of a niche that pragmatic people have left behind a long time ago. Lisp was very influential, but those advancement have made their way into practical languages and lisp has been impractical for many decades at this point.

> This sounds more like someone getting caught up in the pageantry of a niche that pragmatic people have left behind a long time ago.

And once you notice it once, you start noticing it everywhere.

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#74
post #55

Earlier quoted context omitted.

Lisp is eldritch by programming language standards; we are still wrestling with the ramifications of McCarthy's half-page of code.

You think lisp is "weird and sinister or ghostly" and that 'we' are still wrestling with something 66 years later? This sounds more like someone getting caught up in the pageantry of a niche that pragmatic people have left behind a long time ago. Lisp was very influential, but those advancement have made their way into practical languages and lisp has been impractical for many decades at this point.

> those advancement have made their way into practical languages

I agree with this for the most part, though I've yet to see a non-lisp language support macros as nicely as Scheme's syntax-case.

Also, while Lisp's features have made their way into modern languages, there are very few that contain all of them at the same time.

> those advancement have made their way into practical languages

I disagree with this.

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#75
post #55

Earlier quoted context omitted.

Lisp is eldritch by programming language standards; we are still wrestling with the ramifications of McCarthy's half-page of code.

You think lisp is "weird and sinister or ghostly" and that 'we' are still wrestling with something 66 years later? This sounds more like someone getting caught up in the pageantry of a niche that pragmatic people have left behind a long time ago. Lisp was very influential, but those advancement have made their way into practical languages and lisp has been impractical for many decades at this point.

Scheme has pioneered a lot of stuff over the last 30-40 years that is still fresh for most of the PL world, hygienic macros (like Rust is trying to implement), delimited continuations (which underlies Java's new virtual threads, see https://www.youtube.com/watch?v=9vupFNsND6o), efficient closure representations (used all over the place since everybody got lambda fever). Into formal verification? Scheme was there in 1995 https://www.semanticscholar.org/paper/VLISP%3A-A-verified-im...

And there is at least half a dozen things in Racket that I wish mainstream languages could get their ass in gear and copy, but no such luck.

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#76
post #20

Earlier quoted context omitted.

Lisp is not the language for that unfortunately, it is very much an imperative language with better syntax and _some_ macros. Scheme is close but quotation isn't thought about nearly enough. It is generally a CS problem as logic systems with quotation are very much an open problem. I think that types have gotten too much attention and quotation way too little. Macros are basically a way to deal with the fact that nei…

What is the requirement defining "first class quotation"? In support of ways of implementing Scheme hygienic macros, there exists an invention known as syntactic closures. In what ways does a syntactic closure fall short of being a "first class quotation"?

The ability to evaluate _any_ code in an eval.

E.g. (let ((a 10)) (eval '(+ a 1)))

Hygienic macros are just a band aid over the fact that quotation isn't a first class citizen in scheme.

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#77
post #15

Given Peter Norvig's work on Lisp and Python, pity that after 24 years, his "Python for Lisp Programmers" essay from 2000 is still mostly true. Python might have overtaken Lisp's role in AI, but still needs some catching up in tooling. "The two main drawbacks of Python from my point of view are (1) there is very little compile-time error analysis and type declaration, even less than Lisp, and (2) execution time is mu…

> Qualitatively, Python feels about the same speed as interpreted Lisp, but very noticably slower than compiled Lisp

Did you try mypyc?

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#78
post #76

Earlier quoted context omitted.

What is the requirement defining "first class quotation"? In support of ways of implementing Scheme hygienic macros, there exists an invention known as syntactic closures. In what ways does a syntactic closure fall short of being a "first class quotation"?

The ability to evaluate _any_ code in an eval. E.g. (let ((a 10)) (eval '(+ a 1))) Hygienic macros are just a band aid over the fact that quotation isn't a first class citizen in scheme.

Note that this actually works in ancient, dynamically scoped dialects of Lisp, and will work with dynamically scoped variables.

  (progv '(a) '(10) (eval '(+ a 1)))  ;; Common Lisp, TXR Lisp
With lexical scope, what you're looking for is a closure. lambda is your "first class quote".

  [1]> (defmacro fcquote (expr) `(lambda () ,expr))
  FCQUOTE
  [2]> (defun fceval (fcq) (funcall fcq))
  FCEVAL
  [3]> (fceval (let ((a 10)) (fcquote (+ a 10))))
  20
> Hygienic macros are just a band aid ...

Sure, whatever; what I intended to bring up was the specific way of implementing hygienic macros using syntactic closures. Syntactic closures are a way of quoting code, with context. Hygienic macros don't have to be implemented with syntactic closures.

That author you cited seems to be working on something very similar to syntactic closure. The paper has a lot of references, but very few of them are anything Lisp or Scheme related. Looks like the author is working entirely on his own.

In a work like this, I'd expect syntactic closures to be acknowledged, with a discussion of how the work being presented is different.

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#79

This might sound crazy or stupid but I really want to know if there is some Lisp with manual memory management? I love Lisp syntax. People complain about the parentheses but for me they are a blessing. I like how extremely uniform and regular they look. But all Lisps I've seen have garbage collectors. If I could find a Lisp with manual memory management, I could ditch C++ in favor of that Lisp. Is there one?

Carp! It's still experimental and I'd argue the affordances provided by a gc are a part of what makes lisp lisp, but it fits your criteria.

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#80
post #68

Earlier quoted context omitted.

You think lisp is "weird and sinister or ghostly" and that 'we' are still wrestling with something 66 years later? This sounds more like someone getting caught up in the pageantry of a niche that pragmatic people have left behind a long time ago. Lisp was very influential, but those advancement have made their way into practical languages and lisp has been impractical for many decades at this point.

Ah yes, all of the modern practical languages allow you to connect to a running system, redefine a class, and automatically update every existing instance of that class.

Sounds like most scripting languages.
Post reply on HN