Live data from Hacker News

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

norvig.com

11–20 of 101 posts

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

#11

> The beauty of Scheme is that the full language only needs 5 keywords and 8 syntactic forms. Is there a learning resource that covers exactly this for those wanting to write software in lisp in 2024? As "first principle thinkers" in some ways all hackers crave for that "fundamental building blocks approach", a bit like wanting to know how we go from transistors to full computers and every step along the way. Most of…

Many years ago I wrote a simple programming language that would macro expand into lambda calculus statement that could then be compiled down to different sets of combinators - the simplest being just S & K, which are pretty fundamental given how simple they are. The fact that you can express things like recursion in the lambda calculate (see name of our hosts on this site) and therefore in combinators still amazes me.

Not the most efficient approach but it does work.

https://en.wikipedia.org/wiki/SKI_combinator_calculus

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

#13
I think this "lisp as a python one-liner" has come up before:

http://www.chiark.greenend.org.uk/~pcorbett/yvfc.html

The author was a labmate, and the person who introduced me to python. Taking over one of his codebases was rather a formative part of my career. (That particular code was considerably more normal than the one linked above).

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

#14
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 match on trees and transform them, subsume branches or move branches around arbitrarily. You kind of want the matching function and transformation function to be imperative or sometimes like a query.

So use ASTs for behaviour and relationships and imperative LISP macros for transformations and rewriting.

The reason I say this is because I dream of a compositional language where I can create a cell in a spreadsheet and say that it should have these behaviours

  import load-balancing
  import batching
  import backoff
  import backpressure
  import retries
  import durable-execution
  import memory-contiguity
  import memory-alignment
Truly futuristic programming where we we program behaviours.

I am asked to define the terms that these behaviours require.

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

#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 much slower than Lisp, often by a factor of 10 (sometimes by 100 and sometimes by 1). Qualitatively, Python feels about the same speed as interpreted Lisp, but very noticably slower than compiled Lisp. For this reason I wouldn't recommend Python for applications that are (or are likely to become over time) compute intensive (unless you are willing to move the speed bottlenecks into C). But my purpose is oriented towards pedagogy, not production, so this is less of an issue. "

-- https://norvig.com/python-lisp.html

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

#16

> The beauty of Scheme is that the full language only needs 5 keywords and 8 syntactic forms. Is there a learning resource that covers exactly this for those wanting to write software in lisp in 2024? As "first principle thinkers" in some ways all hackers crave for that "fundamental building blocks approach", a bit like wanting to know how we go from transistors to full computers and every step along the way. Most of…

You can try to implement your own Scheme like this,

"An Incremental Approach to Compiler Construction"

http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

You will get you own compile to native code Scheme compiler, and then take it from there.

Don't care about performance, only the learning experience.

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

#17
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…

> (1) there is very little compile-time error analysis and type declaration

There's been a lot of improvement on that front.

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

#18
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…

> (1) there is very little compile-time error analysis and type declaration There's been a lot of improvement on that front.

It's still… not the same. In CL (and specially with SBCL), we get compile time (type) errors and warnings at the blink of an eye, when we compile a single function with a keystroke (typically C-c C-c in Slime).

And there's also been improvement, see Coalton for a ML on top of CL. (https://github.com/coalton-lang/coalton/) (and SBCL itself evolves)

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

#19

Or you can just from fakelisp import * And turn your Python into a Lisp. https://github.com/akalenuk/fakelisp

Not exactly the same (doesn't embed into the source like this did), but I believe Hylang[0] is the best Lisp package available for modern Python.

[0] https://github.com/hylang/hy

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

#20

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…

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 neither lisp nor scheme have first class quotation which you can evaluate at leisure. I understand why they've done it for efficiency reason, but I think we should have at least one language that gets quotation right.

https://imps.mcmaster.ca/doc/qe-in-church.pdf

The above paper is the state of the art and the author there is pretty much the only person I know who has been working on the problem long term.

Basically reading all his publications will get you to open research problems of which there are many.

Post reply on HN