8 ms·

> Most programming languages have several syntax rules. Lisp has one: everything is a list. Oh, not again. The author is confusing s-expression syntax with Li

by lispm 11y ago

> Most programming languages have several syntax rules. Lisp has one: everything is a list. Oh, not again. The author is confusing s-expression syntax with Lisp syntax. Even s-expressions are more than lists (conses, cyclic conses, symbols, vectors, strings, various numbers, structures, ...) and the s-expression reader knows about more than pure s-expressions - for example comments. Not every s-expression is a valid Lisp expression. For example (let "let") is not a valid Common Lisp expression. The syntax for LET is: let ({var | (var [init-form])}*) declaration* form* => result* This is also using the syntax definition for 'declaration' and 'form'. Lisp has built-in syntax (provided by special operators in Common Lisp) and arbitrary complex syntax provided by macros. This is valid for other languages with a notation based on s-expressions, like Scheme or Clojure.

chrisoakman 11y ago
I can assure you the author of Parinfer is aware of this distinction ;) That sentence is an oversimplification to give context to the rest of the content in that section. Should probably have an asterisk to clarify.
- lispm 11y ago
  It's one of the sentences which creates endless confusions and a false image of Lisp. 'Everything is a list'. Oh, Lisp has only one data structure? Lisp is difficult to read, because it has no other syntax? Lisp is a primitive language and not usable for real programmers... etc. etc. It also creates the impression that even proponents of Lisp-like languages don't actually understand the basics...
  - oconnore 11y ago
    Who is endlessly confused? Who suspects that the author of a neat lisp editor plugin has never written a non-trivial line of Common Lisp, Clojure, or Scheme? What are the chances that people in either category are also curious and excited to experiment with novel editing techniques?
    - lispm 11y ago
      > Who is endlessly confused? Everyone who reads or hears this sentence. I've heard 'everything is a list' a zillion times already. It's just wrong. In every way.
      - jsprogrammer 11y ago
        A LISP program is a list of characters.
        pavelludiq 11y ago
        If we're going to be super pedantic, the Common Lisp spec actually defines code as: "code n. 1. Trad. any representation of actions to be performed, whether conceptual or as an actual object, such as forms, lambda expressions, objects of type function, text in a source file, or instruction sequences in a compiled file. This is a generic term; the specific nature of the representation depends on its context. " http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_c.htm#code http://www.lispworks.com/documentation/HyperSpec/Body/26_glo...
        lispm 11y ago
        Actually not. A Lisp program is data. The Lisp system does not care if it comes from a text file or if it is constructed as data by a program: (list '+ '1 '2) constructs a program which can be evaluated.
        jsprogrammer 11y ago
        I have thought about this response a bit, but, all I see here are more lists of characters.
        lispm 11y ago
        Use Lisp and you will see.
Blackthorn 11y ago
We all knew what it meant, including the author. This is pointlessly pedantic.
- lispm 11y ago
  It's not. Explain Lisp to people not by treating them as idiots who won't understand that not everything is a list. There are numbers, vectors, strings, and various other forms of syntax in Lisp. (john "123" 1) consists of a list, a symbol, a string, an integer |hi there| is a symbol #*1010101011 is a bit vector #2A((1 1 1) (1 1 1)) is a 2d array and so on. Also look up the current Scheme report and see its syntax definition. 'Everything is a list' is fooling the reader and treating him/her like an idiot.
  - munificent 11y ago
    I'm pretty sure people understand that "everything is a list" doesn't mean there are no primitive literal types in the language.
    - lispm 11y ago
      An array, a structure or a cyclic cons structure are just as basic as a list. In Lisp the cons structure is actually the primitive. Lists are built on top.
    - gammafactor 11y ago
      I'm pretty sure you're an idiot.
      - dang 11y ago
        > I'm pretty sure you're an idiot. We ban accounts that do this. Please read the guidelines and post civilly and substantively, or not at all. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html
coldtea 11y ago
>The author is confusing s-expression syntax with Lisp syntax. Then again what he says is true for 99% of the cases, and a good simplification. >Even s-expressions are more than lists (conses, cyclic conses, symbols, vectors, strings, various numbers, structures, ...) Still expressed as lists when it comes to the syntax level.
- lispm 11y ago
  > Then again what he says is true for 99% of the cases, and a good simplification. It's not. Read it slowly: only a subset of s-expressions are valid Lisp programs. Examples for invalid Lisp programs, even though valid s-expressions: (cl:if x > 1 t nil) ; IF takes 2 or three forms ((cl:lambda) (a) a) ; not a valid lambda expression (cl:let "a let expression" ((a 1)) (+ a 1)) ; the second element should be a list of bindings (cl:defun foo args (length args)) ; arguments needs to be a list (cl:let ((a nil t)) a) ; a binding is a variable or a list of symbol/value and so on. Lisp syntax is not the syntax of s-expressions. Lisp syntax is defined ON TOP of s-expressions. > Still expressed as lists when it comes to the syntax level. Comments are not expressed as lists. Feature expressions are not lists. etc etc...
  - coldtea 11y ago
    >only a subset of s-expressions are valid Lisp programs. Sure, but the thing we're debating is whether "all s-expressions are valid Lisp programs" (that would be a miracle actually), but whether Lisp syntax is all lists. And all those examples are still lists -- that the lists can also contain other items inside them, or that underneath they are implemented as cons etc, doesn't really change that. >Comments are not expressed as lists. They are not retained anyway when the strings are parsed to the "live" AST (AFAIK), so they are an exception to the other syntax in that too.
    - lispm 11y ago
      The page says: > Most programming languages have several syntax rules. Lisp has one: everything is a list. The first element is a function name, and the rest are its arguments. Thus, the language is simply a collection of compile- and run-time functions, trivially extensible. Step by step. > Lisp has one syntax rule: everything is a list. That's wrong. completely wrong. 'everything is a list' is not THE ONE syntax rule of Lisp. Lisp, like most other programming languages, has MANY syntax rules. A defining feature of current Lisp dialects is even that the syntax rules are programmer extensible and thus Lisp has an unbounded number of syntax rules. Thus the complete opposite is true: Lisp has arbitrary many syntax rules. > The first element is a function name, and the rest are its arguments. That's also wrong. It always was. Lisp has since day zero supported more than just function call forms. Valid Lisp expressions: 3 "1 2" ((lambda (a) a) 1) ; (lambda (a) a) is not a function name (defun foo () ()) ; defun is not a function name (let ((a 1)) a) ; let is not a function name > Thus, the language is simply a collection of compile- and run-time functions, trivially extensible. I would not even know what that actually might mean...

by lispm 11y ago

chrisoakman 11y ago

I can assure you the author of Parinfer is aware of this distinction ;) That sentence is an oversimplification to give context to the rest of the content in that section. Should probably have an asterisk to clarify.

lispm 11y ago
It's one of the sentences which creates endless confusions and a false image of Lisp. 'Everything is a list'. Oh, Lisp has only one data structure? Lisp is difficult to read, because it has no other syntax? Lisp is a primitive language and not usable for real programmers... etc. etc. It also creates the impression that even proponents of Lisp-like languages don't actually understand the basics...
- oconnore 11y ago
  Who is endlessly confused? Who suspects that the author of a neat lisp editor plugin has never written a non-trivial line of Common Lisp, Clojure, or Scheme? What are the chances that people in either category are also curious and excited to experiment with novel editing techniques?
  - lispm 11y ago
    > Who is endlessly confused? Everyone who reads or hears this sentence. I've heard 'everything is a list' a zillion times already. It's just wrong. In every way.
    - jsprogrammer 11y ago
      A LISP program is a list of characters.
      - pavelludiq 11y ago
        If we're going to be super pedantic, the Common Lisp spec actually defines code as: "code n. 1. Trad. any representation of actions to be performed, whether conceptual or as an actual object, such as forms, lambda expressions, objects of type function, text in a source file, or instruction sequences in a compiled file. This is a generic term; the specific nature of the representation depends on its context. " http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_c.htm#code http://www.lispworks.com/documentation/HyperSpec/Body/26_glo...
      - lispm 11y ago
        Actually not. A Lisp program is data. The Lisp system does not care if it comes from a text file or if it is constructed as data by a program: (list '+ '1 '2) constructs a program which can be evaluated.
        jsprogrammer 11y ago
        I have thought about this response a bit, but, all I see here are more lists of characters.
        lispm 11y ago
        Use Lisp and you will see.

Blackthorn 11y ago

We all knew what it meant, including the author. This is pointlessly pedantic.

lispm 11y ago
It's not. Explain Lisp to people not by treating them as idiots who won't understand that not everything is a list. There are numbers, vectors, strings, and various other forms of syntax in Lisp. (john "123" 1) consists of a list, a symbol, a string, an integer |hi there| is a symbol #*1010101011 is a bit vector #2A((1 1 1) (1 1 1)) is a 2d array and so on. Also look up the current Scheme report and see its syntax definition. 'Everything is a list' is fooling the reader and treating him/her like an idiot.
- munificent 11y ago
  I'm pretty sure people understand that "everything is a list" doesn't mean there are no primitive literal types in the language.
  - lispm 11y ago
    An array, a structure or a cyclic cons structure are just as basic as a list. In Lisp the cons structure is actually the primitive. Lists are built on top.
  - gammafactor 11y ago
    I'm pretty sure you're an idiot.
    - dang 11y ago
      > I'm pretty sure you're an idiot. We ban accounts that do this. Please read the guidelines and post civilly and substantively, or not at all. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html

coldtea 11y ago

>The author is confusing s-expression syntax with Lisp syntax. Then again what he says is true for 99% of the cases, and a good simplification. >Even s-expressions are more than lists (conses, cyclic conses, symbols, vectors, strings, various numbers, structures, ...) Still expressed as lists when it comes to the syntax level.

lispm 11y ago
> Then again what he says is true for 99% of the cases, and a good simplification. It's not. Read it slowly: only a subset of s-expressions are valid Lisp programs. Examples for invalid Lisp programs, even though valid s-expressions: (cl:if x > 1 t nil) ; IF takes 2 or three forms ((cl:lambda) (a) a) ; not a valid lambda expression (cl:let "a let expression" ((a 1)) (+ a 1)) ; the second element should be a list of bindings (cl:defun foo args (length args)) ; arguments needs to be a list (cl:let ((a nil t)) a) ; a binding is a variable or a list of symbol/value and so on. Lisp syntax is not the syntax of s-expressions. Lisp syntax is defined ON TOP of s-expressions. > Still expressed as lists when it comes to the syntax level. Comments are not expressed as lists. Feature expressions are not lists. etc etc...
- coldtea 11y ago
  >only a subset of s-expressions are valid Lisp programs. Sure, but the thing we're debating is whether "all s-expressions are valid Lisp programs" (that would be a miracle actually), but whether Lisp syntax is all lists. And all those examples are still lists -- that the lists can also contain other items inside them, or that underneath they are implemented as cons etc, doesn't really change that. >Comments are not expressed as lists. They are not retained anyway when the strings are parsed to the "live" AST (AFAIK), so they are an exception to the other syntax in that too.
  - lispm 11y ago
    The page says: > Most programming languages have several syntax rules. Lisp has one: everything is a list. The first element is a function name, and the rest are its arguments. Thus, the language is simply a collection of compile- and run-time functions, trivially extensible. Step by step. > Lisp has one syntax rule: everything is a list. That's wrong. completely wrong. 'everything is a list' is not THE ONE syntax rule of Lisp. Lisp, like most other programming languages, has MANY syntax rules. A defining feature of current Lisp dialects is even that the syntax rules are programmer extensible and thus Lisp has an unbounded number of syntax rules. Thus the complete opposite is true: Lisp has arbitrary many syntax rules. > The first element is a function name, and the rest are its arguments. That's also wrong. It always was. Lisp has since day zero supported more than just function call forms. Valid Lisp expressions: 3 "1 2" ((lambda (a) a) 1) ; (lambda (a) a) is not a function name (defun foo () ()) ; defun is not a function name (let ((a 1)) a) ; let is not a function name > Thus, the language is simply a collection of compile- and run-time functions, trivially extensible. I would not even know what that actually might mean...