6 ms·

pg wrote about this years ago. >If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no

pg wrote about this years ago. >If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed. source: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

jesstaa 13y ago
It's as if lisp was originally designed to be an intermediate language for computer generated parse trees....and not a language for people to read.
- vog 13y ago
  If you say "S-expressions" instead of "LISP", this is perfectly true! The syntax of S-expressions was only meant to be used for LISP data structures, while programming was meant to happen in another syntax called "M-expressions" [1], which was to be converted to S-expressions by the compiler. However, the programmers liked to use S-expressions directly, so M-expressions were never actually implemented. In that sense, the LISP syntax (S-expressions) were ideed designed as an intermediate language, not to be used by programmers directly (except for plain data structures). [1] https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression
  - crntaylor 13y ago
    This is really interesting - I didn't know about that snippet of Lisp history. So the expression we'd write today as (car (append '(a b c) '(d e f))) Would originally have been written in M-expression form as car[append[(a b c); (d e f)]] Programming in Lisp might be a very different experience if M-expressions had caught on!
    - Anon84 13y ago
      It would be called programming in Mathematica ;)
- goldenkey 13y ago
  It's not as if..it is truly the case. That's why only nutters use LISP for large projects. Who really wants to wrap every S-Expression in parenthesis? Talk about painstaking and what an eye-sore. If only M-Expressions caught on, LISP could be decent. But really, it's just making you write your program as a data structure because that makes it easier for the compiler to process. So... Ruby: good for developers, bad for the JIT compiler (slow) LISP: awful for developers, good for the compiler -> machine (fast) Is the tradeoff worth it? Not at all. Most LISP intros start by convincing you that you'll eventually get used to your code looking like a sack of parenthesis. No thanks, I shouldn't need to get used to staring at overburdened verbosity for the compilers' sake - build something better. Wait..we have other languages that are fast and look nice. And many even process into a well-formed AST. Okay, thank heavens.
  - sklivvz1971 13y ago
    yeah, the trade off are generally c-based languages.
  - aerique 13y ago
    I disagree that Lisp is awful for developers. To me and many others it looks quite pleasant while the "other languages that look nice" actually look like a needless mess of braces, brackets, asterisks, comma's, etc. etc. Only Python comes close IMHO but has many other downsides.
    - goldenkey 13y ago
      Brackets, asterisks, and commas give array indexing, pointers, and the clean separation of function arguments. (incf (elt vector 2)) ..versus.. ++vector[2] which one is more readable? LISP is not to be taken seriously. It's an academic curiosity, and cute, novel, not a language that needs continued zealots. It has no market share..the reasons are always going to be the same. The language is esoteric. I wouldn't program anything serious in JSON so why would I use LISP, where every semantic is a list..not even a hashmap. http://imgs.xkcd.com/comics/lisp_cycles.png http://imgs.xkcd.com/comics/lisp_cycles.png "These are your fathers' parenthesis"
velis_vel 13y ago
Yes, and he's still wrong. You don't write 'directly in parse trees', you write in text that gets converted to parse trees. The conversion is very simple, to be sure, but it still exists.
- Chattered 13y ago
  When writing an S-expression of Lisp code, you're just one quote symbol off writing the list literal that evaluates to the code's parse tree. Modulo whitespace, the parse-tree prints as code. That's what we mean when we say you write directly in parse-trees. You're writing the string representation of those parse-trees.
  - velis_vel 13y ago
    Right, but it seems inaccurate to me to say that Lisp code 'has no syntax'. What do you call the reason that 2927(foo"bar. isn't a valid Lisp program? Alternately: If I augment Python by letting you surround a block of Python code with curly braces in order to get an object representing the corresponding AST, does that mean that I can write Python directly in parse trees? :P
    - Chattered 13y ago
      It's always called a "read" error. If you're working at the REPL, it's detected at the Read phase of the Read-Eval-Print-Loop. It is, of course, a read-syntax error. But the fact that the Read phase can be usefully separated from the Eval phase is a distinguishing feature of Lisp, and why it makes sense to say, at least, that Lisp has no concrete syntax, only abstract syntax. Lisp programmers fluently think in terms of the abstract syntax their code generates, because they read and write in the string representation of that abstract syntax. That's why it makes sense for the Lisp eval function, unlike the eval function in other dynamic languages, to take lists as input rather than strings. That's why a metacircular interpreter in Lisp will be written to input lists. That's why a DSL in Lisp written as a custom evaluation function will be an interpreter for lists. The Lisp language is defined with respect to the list data-structure, rather than strings. On your Python idea: the problem is that no-one would ever use Python code as the literal representation of Python's abstract syntax. It would be entirely backward, anyway. Lisp starts as a notation for a data-structure rich enough to represent abstract syntax (symbolic expressions) and then defines a language in terms of this data structure. The philosophy of this is understood when we realise that the roots of Lisp are in metalanguages and logic.

jesstaa 13y ago

It's as if lisp was originally designed to be an intermediate language for computer generated parse trees....and not a language for people to read.

vog 13y ago
If you say "S-expressions" instead of "LISP", this is perfectly true! The syntax of S-expressions was only meant to be used for LISP data structures, while programming was meant to happen in another syntax called "M-expressions" [1], which was to be converted to S-expressions by the compiler. However, the programmers liked to use S-expressions directly, so M-expressions were never actually implemented. In that sense, the LISP syntax (S-expressions) were ideed designed as an intermediate language, not to be used by programmers directly (except for plain data structures). [1] https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression
- crntaylor 13y ago
  This is really interesting - I didn't know about that snippet of Lisp history. So the expression we'd write today as (car (append '(a b c) '(d e f))) Would originally have been written in M-expression form as car[append[(a b c); (d e f)]] Programming in Lisp might be a very different experience if M-expressions had caught on!
  - Anon84 13y ago
    It would be called programming in Mathematica ;)
goldenkey 13y ago
It's not as if..it is truly the case. That's why only nutters use LISP for large projects. Who really wants to wrap every S-Expression in parenthesis? Talk about painstaking and what an eye-sore. If only M-Expressions caught on, LISP could be decent. But really, it's just making you write your program as a data structure because that makes it easier for the compiler to process. So... Ruby: good for developers, bad for the JIT compiler (slow) LISP: awful for developers, good for the compiler -> machine (fast) Is the tradeoff worth it? Not at all. Most LISP intros start by convincing you that you'll eventually get used to your code looking like a sack of parenthesis. No thanks, I shouldn't need to get used to staring at overburdened verbosity for the compilers' sake - build something better. Wait..we have other languages that are fast and look nice. And many even process into a well-formed AST. Okay, thank heavens.
- sklivvz1971 13y ago
  yeah, the trade off are generally c-based languages.
- aerique 13y ago
  I disagree that Lisp is awful for developers. To me and many others it looks quite pleasant while the "other languages that look nice" actually look like a needless mess of braces, brackets, asterisks, comma's, etc. etc. Only Python comes close IMHO but has many other downsides.
  - goldenkey 13y ago
    Brackets, asterisks, and commas give array indexing, pointers, and the clean separation of function arguments. (incf (elt vector 2)) ..versus.. ++vector[2] which one is more readable? LISP is not to be taken seriously. It's an academic curiosity, and cute, novel, not a language that needs continued zealots. It has no market share..the reasons are always going to be the same. The language is esoteric. I wouldn't program anything serious in JSON so why would I use LISP, where every semantic is a list..not even a hashmap. http://imgs.xkcd.com/comics/lisp_cycles.png http://imgs.xkcd.com/comics/lisp_cycles.png "These are your fathers' parenthesis"

velis_vel 13y ago

Yes, and he's still wrong. You don't write 'directly in parse trees', you write in text that gets converted to parse trees. The conversion is very simple, to be sure, but it still exists.

Chattered 13y ago
When writing an S-expression of Lisp code, you're just one quote symbol off writing the list literal that evaluates to the code's parse tree. Modulo whitespace, the parse-tree prints as code. That's what we mean when we say you write directly in parse-trees. You're writing the string representation of those parse-trees.
- velis_vel 13y ago
  Right, but it seems inaccurate to me to say that Lisp code 'has no syntax'. What do you call the reason that 2927(foo"bar. isn't a valid Lisp program? Alternately: If I augment Python by letting you surround a block of Python code with curly braces in order to get an object representing the corresponding AST, does that mean that I can write Python directly in parse trees? :P
  - Chattered 13y ago
    It's always called a "read" error. If you're working at the REPL, it's detected at the Read phase of the Read-Eval-Print-Loop. It is, of course, a read-syntax error. But the fact that the Read phase can be usefully separated from the Eval phase is a distinguishing feature of Lisp, and why it makes sense to say, at least, that Lisp has no concrete syntax, only abstract syntax. Lisp programmers fluently think in terms of the abstract syntax their code generates, because they read and write in the string representation of that abstract syntax. That's why it makes sense for the Lisp eval function, unlike the eval function in other dynamic languages, to take lists as input rather than strings. That's why a metacircular interpreter in Lisp will be written to input lists. That's why a DSL in Lisp written as a custom evaluation function will be an interpreter for lists. The Lisp language is defined with respect to the list data-structure, rather than strings. On your Python idea: the problem is that no-one would ever use Python code as the literal representation of Python's abstract syntax. It would be entirely backward, anyway. Lisp starts as a notation for a data-structure rich enough to represent abstract syntax (symbolic expressions) and then defines a language in terms of this data structure. The philosophy of this is understood when we realise that the roots of Lisp are in metalanguages and logic.