[dead]
(How to Write a (Lisp) Interpreter (In Python)) (2010)
81–90 of 101 posts
Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)
#82Earlier quoted context omitted.
I made a lisp that's somewhat close to what you described. It's a freestanding lisp that targets the Linux kernel directly. No libraries, not even libc. https://github.com/lone-lang/lone
The idea would be to write a port in rv64 assembly, and to run it in a x86_64/arm64 interpreter (for legacy support). I am currently written rv64 assembly for some project, and at the same time I am writting a x86_64 interperter for this rv64 assembly code. rv64 assembly is the new C.
Really?
I would assume any assembly language is worse to program than C
Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)
#83Earlier quoted context omitted.
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)) (fcquo…
Syntactic closures are a way to hide the fact that lambdas are the only abstraction in lambda calculus.
The work that I cited has types _and_ quotation as first class abstractions.
It's a bit like asking to explain proof theory in terms of Godel numbers. Sure you can technically do it. You're completely missing the point if you do however.
Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)
#84The title alone is already worth an upvote
Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)
#85Earlier quoted context omitted.
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)) (fcquo…
Syntactic closures are a way to hide the fact that lambdas are the only abstraction in lambda calculus. The work that I cited has types _and_ quotation as first class abstractions. It's a bit like asking to explain proof theory in terms of Godel numbers. Sure you can technically do it. You're completely missing the point if you do however.
I think syntactic closures don't have to be concerned with type, because their job is just to ensure that the symbols included in a quote refer to what they are supposed to refer to, regardless to where that quote is moved. When the closures are evoked, reasoning about types can take place then.
Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)
#86Earlier quoted context omitted.
The idea would be to write a port in rv64 assembly, and to run it in a x86_64/arm64 interpreter (for legacy support). I am currently written rv64 assembly for some project, and at the same time I am writting a x86_64 interperter for this rv64 assembly code. rv64 assembly is the new C.
Really? I would assume any assembly language is worse to program than C
It is more upfront work for sure. But you get immunity from the planned obsolescence of syntax feature creeps from ISO or gcc extensions (a 5-10 years cycle)... and from compiler implementations.
Additionnally, if we are honnest with ourselves for a lot of programs, from a life cycle perspective, coding time of the bulk is actually negligictible. It is not the case with all types of programs though, but for a lot of system programs, this is very true.
And rv64 is supposed to become THE ISA standard. One of the main reasons for C existence is ISA abstraction which is kind of gone here. Of course, I wish risc-v to be a success.
Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)
#87Earlier 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.
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…
Insert meme of Nolan Grayson, representing Lisp/Scheme/Racket programmers, pointing at fighter jets labeled "transpilers" and saying: "Look at what they need to mimic just a fraction of our power!"
Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)
#88Earlier quoted context omitted.
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.
Scripting languages typically do not retroactively update existing instances. Afaik Common Lisp and Smalltalk are the only languages that do this.
Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)
#89I 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).
That is truly impressive.
Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)
#90Earlier quoted context omitted.
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.
What I was thinking about in your post was the the statement "[Lisp] is very much an imperative language with better syntax and _some_ macros". Of course some lisp-family languages are very much not imperative and some get by without macros (e.g. Clojure).
Can you imagine a language with such a first-class quoting system?