Ask HN: Is Lisp Simple?
I thought Lisp was suppose to be simple in that: it's all just lists.
I thought everything would just be s-expressions, and be consistent, so it would be easy to read to figure out what is going on.
But it seems like there are so many special constructs and macros, that make it hard to read. And behind the scenes of these macros it gets really complicated. Whereas in other languages its readable the whole way down.
E.g. How am I suppose to read this? How does it de-construct to s-expressions...and does it even? What is implemented natively in the interpreter? Does that language have built-in keywords?
I thought everything was suppose to be like: `(left . (left . right) )`.
(loop for i in '(1 2 3)
when (> i 1)
return i)
It seems as if there are actually a ton more special case primitives I need to know, when I could get away with a lot less syntax in other languages to be productive.Like maybe there is some simplicity at the very bottom, but that doesn't seem to matter in day-to-day programming.
Another example, the first think I see when I look at the language basics of how to make a function:
https://lispcookbook.github.io/cl-cookbook/functions.html:
(defun <name> (list of arguments)
"docstring"
(function body))
How do I read this as an s-expression? The loop macro is an interesting example as its pretty much a mini language within Lisp just for looping purposes that doesn't use the normal s-expression based syntax - which is either a bad thing or a great example of how powerful Lisp can be... Personally, when I used to write Common Lisp for a living (a long long time ago) I was very fond of loop.
As for "it's all just lists" - Common Lisp directly supports a variety of different mechanisms for structuring data, including the rather wonderful CLOS.
CLOS looks really interesting. So many good ideas. A lot that I have been thinking about for a while.
https://lispcookbook.github.io/cl-cookbook/clos.html:
> arguably one of the most powerful object systems available in any language.
https://en.wikipedia.org/wiki/Common_Lisp_Object_System:
> Another unusual feature is that methods do not "belong" to classes; classes do not provide a namespace for generic functions or methods. Methods are defined separately from classes, and they have no special access (e.g. "this", "self", or "protected") to class slots.
Love this.
And the multiple dispatch.
> :before, :after, and :around
Guess these are similar to aspect-oriented programming. Maybe useful for plugin systems.
> change-class
This looks pretty cool for GUI apps. So many times you want to change a component to something else.
It's simpler than most languages that have a generative grammar.
If you really want to understand it I'd suggest reading this
https://groups.csail.mit.edu/mac/ftpdir/scheme-7.4/doc-html/...
and reading it again, thinking about it, writing some code, reading it again and such. It is astonishing short for a specification for a real programming language and will become clear to you if you live with it. I count 30 "special forms" in there
https://groups.csail.mit.edu/mac/ftpdir/scheme-7.4/doc-html/...
and 24 in the Common Lisp spec
https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node59.html
although this claims the minimum is 9
https://stackoverflow.com/questions/3482389/how-many-primiti...
See also
> it's all just lists. Yes, Lisp code is made up of lists.
> But it seems like there are so many special constructs and macros, that make it hard to read.
> (loop for i in '(1 2 3)
Common Lisp is a "programmable programming language" meaning that it's possible to make macros like the loop macro that aren't even what many consider "Lispy" - lots of people who otherwise like Common Lisp dislike the loop macro. But, it's a good example of a DSL and how far you can go with making one. Of course, there are other ways to do iteration besides loop, both standard built-in forms such as do or dolist, and even 3rd party libraries like series or iterate.
Also, when macros are expanded they resolve to lists - even the loop macro.
OTOH, something like MIT Scheme which was used in SICP is a much simpler Lisp compared to CL.
If you are using Common Lisp, the HyperSpec is an awesome resource:
http://www.lispworks.com/documentation/HyperSpec/Front/index...
There's a community version of the spec as well: https://cl-community-spec.github.io/pages/index.html
> (defun <name> (list of arguments) > "docstring" > (function body))
> How do I read this as an s-expression?
It's still a list.
You can re-write it as:
(let ((my-list '(defun <name> (list of arguments) "docstring" (function body))))
(print (first my-list))
(print (second my-list))
(print (third my-list))
(print (fourth my-list)))
It will print: DEFUN
<NAME>
(LIST OF ARGUMENTS)
"docstring"
If "docstring" appears twice when you run the above, that's because it's the value produced by the final form in the block, so it shows up as the return value of the block.> I thought everything was suppose to be like: `(left . (left . right) )`.
Could be, but you don't need the "." (or the list as so-called "cons pairs"). (a b c ...) is enough.
> It seems as if there are actually a ton more special case primitives I need to know
You need to know a handful of special forms like and, cond, let etc (corresponding roughly to keywords in other languages). Everything uses those with the same syntax (nested lists), with an exception:
Normally (a b c) means call function a with arguments b c. If you want to treat it as a list you can use the quote "function":
(quote a b c)
For convenience this can also be written as: '(a b c)
> (loop for i in '(1 2 3)
when (> i 1)
return i)Loop is a macro, a user-defined syntax that can evaluate its arguments in a special way. It's not part of the core language, even if it comes with it. Rather it is implemented in Lisp itself.
You can just not use it, it's neither core Lisp, nor essential. If you do want to use it, or have to read the code of someone that does use, it's pretty easy to understand. It was created so people can have their familiar for loop in Lisp too.
> How do I read this as an s-expression?
What do you mean? This is already an s-expression. Or it would be, if you actually write an instance of this, this is just an example with placeholders. An instance would be something like:
(defun double (a) "Doubles a number" (+ a a))
corresponding to the:defun = special form (similar to "def" or "function" in other languages)
double = name of function we define
(a) = parameter list of a single parameter: a
"Doubles a number" = docstring, similar to the """docstrings" in Python, descriptive metadata string about the function
(+ a a) = add a to a in prefix (operator first) math notation
(quote a b c) does not exist in Lisp. QUOTE takes exactly one argument, the object to quote. It's a special operator.
> defun = special form'(a b c) is (quote (a b c))DEFUN is not really a form in the standard. It's a operator. It's even not a special operator. It's a macro operator.
A form is something meant to be evaluated. One could evaluate the symbol DEFUN, but by default it has no value.
So are these "specials" being parsed by a grammar?
Would be interesting to see how the interpreter works actually...
I would guess it checks what `defun` is, which is a macro...then expands it, and the expansion should ultimately result in an s-expression, which is then parses? Is this right?
>Would be interesting to see how the interpreter works actually...
It's quite easy to see, there are interpeters for Lisp in like 20 lines or so.
Here's a good one:
(It has the full code in a link towards the bottom)
There's also this:
> I would guess it checks what `defun` is, which is a macro...then expands it, and the expansion should ultimately result in an s-expression, which is then parses? Is this right?
Yes, but macros (like special forms, but macros can be user implementable) have some "special" powers regarding controlling the evaluation of the code they produce.
Here's some more discussion with examples:
https://stackoverflow.com/questions/42470940/how-is-the-defu...
Thanks! Lisp is so damn cool.
(defun foo (a) (+ a 1)) is a s-expression. For evaluation Lisp expands the DEFUN macro then and this returns a new s-expression. Which then is evaluated.
> So are these "specials" being parsed by a grammar?
Every special operator (and there are only a limited amount and this is not user extensible) needs to be implemented by a Lisp source interpreter or a Lisp compiler. Other tools like a code walker also need to know the syntax.
oops, I shouldn't post drunk
> It seems as if there are actually a ton more special case primitives I need to know, when I could get away with a lot less syntax in other languages to be productive.
I think most special forms do not complicate syntax, as they look like your standard s-expressions, they just have differing semantics from regular functions.
If you look at Common Lisp, I feel like you got a point. It is a huge and complicated language, and while it embodies many of the nice Lisp characteristics, I feel like minimalism certainly is not one of them. But there are other Lisps/Schemes that are much smaller, with a lot less special forms.
> I think most special forms do not complicate syntax, as they look like your standard s-expressions
Take LET:
It does not look like (foo arg0 arg1 ... argn).(let ((a b) (c d) e (f g)) (declare (type integer a)) (+ a b c d e f g))Instead it takes a binding list, which is not evaluated. Where bindings can take a variable and a value. The value is evaluated, the variable not. The follows a declaration, which is not evaluated either, but which can be used by the compiler... There are lots of declarations forms: allocation, scope, optimization, types, ...
> I thought Lisp was suppose to be simple in that: it's all just lists.
"Lisp is simple" is mainly an ignorant meme that is used to belittle the interests of people who work in, or on, some kind of Lisp. There are simple aspects, but the aspects are numerous and the combination is complex.
Lisp has kept bright minds busy for sixty years and continues to do so.
Making a production Lisp from scratch is a pretty big undertaking.