The Roots of LISP, by Paul Graham.
This is one of the hardest readings that we had to do in the course. During our programming languages course we have been working with Clojure, a new dialect of LISP that makes everything a little bit more readable. Trying to extrapolate everything we know in Clojure to LISP is not hard, but it's not trivial either. So if you want to go ahead and read The Roots of Lisp, by Paul Graham, you better have a solid foundation of Clojure or any LISP dialect that you are familiar with.
So after giving you this brief introduction let's get right into a review to this reading.
Paul Graham made a review of what John McCarthy found when he discovered this new dialect for making mathematical notation more readable. Let's get into the main points of the reading, so that you can go ahead and read it again by yourself.
1.- Using lists for both data and code.
One of the things that's probably the most weird to understand is this little sentence right here, using lists for both data and code.
To understand this you have to understand first how the quote operator works. The quote function simply returns the value that it receives unevaluated. For example if we write:
> (quote '(+ a b))
=>'(+ a b)
As you can see, the quote operator left everything it received as an argument unevaluated, even though what it received was actually a function that's supposed to sum a and b. Which leads us to the second thing you have to understand.
Functions are called through lists. As a matter of fact everything in Lisp is translated into lists and understood through them. Consider this examples:
> (+ 1 2)
=> 3
So functions are understood through lists as well, where the first element of the list is the function to be applied and the rest of the elements of the list is the arguments that the function uses to execute.
Now consider the fact that you can leave certain parts or certain function calls unevaluated, that gives the programmer the possibility to understand how Lisp code is made internally, which is a very powerful function because then you can write interpreters for practically any other Lisp dialect without having to dig a lot into them.
This is one of the hardest readings that we had to do in the course. During our programming languages course we have been working with Clojure, a new dialect of LISP that makes everything a little bit more readable. Trying to extrapolate everything we know in Clojure to LISP is not hard, but it's not trivial either. So if you want to go ahead and read The Roots of Lisp, by Paul Graham, you better have a solid foundation of Clojure or any LISP dialect that you are familiar with.
So after giving you this brief introduction let's get right into a review to this reading.
Paul Graham made a review of what John McCarthy found when he discovered this new dialect for making mathematical notation more readable. Let's get into the main points of the reading, so that you can go ahead and read it again by yourself.
1.- Using lists for both data and code.
One of the things that's probably the most weird to understand is this little sentence right here, using lists for both data and code.
To understand this you have to understand first how the quote operator works. The quote function simply returns the value that it receives unevaluated. For example if we write:
> (quote '(+ a b))
=>'(+ a b)
As you can see, the quote operator left everything it received as an argument unevaluated, even though what it received was actually a function that's supposed to sum a and b. Which leads us to the second thing you have to understand.
Functions are called through lists. As a matter of fact everything in Lisp is translated into lists and understood through them. Consider this examples:
> (+ 1 2)
=> 3
So functions are understood through lists as well, where the first element of the list is the function to be applied and the rest of the elements of the list is the arguments that the function uses to execute.
Now consider the fact that you can leave certain parts or certain function calls unevaluated, that gives the programmer the possibility to understand how Lisp code is made internally, which is a very powerful function because then you can write interpreters for practically any other Lisp dialect without having to dig a lot into them.
Comments
Post a Comment