4 ms·

Macros are one thing that you easily get from that syntax. And I would argue that it's far less of a footgun than you make it out to be. But really there are m

by dgb23 4y ago

Macros are one thing that you easily get from that syntax. And I would argue that it's far less of a footgun than you make it out to be. But really there are many things that aren't mentioned such as Editor/IDE tooling, in-editor REPL, evaluating expressions, debugging, structural editing, code navigation, formatting... Your example is actually kind of misleading, because the second variation is much closer to how you write in a Lisp than the first. It would really be something like: ``` (def inc-all (partial map inc)) ``` It really makes no sense to use a Lisp in a non expression based manner. The syntax is inherently optimized for it.

kerkeslager 4y ago
> Your example is actually kind of misleading, because the second variation is much closer to how you write in a Lisp than the first. That's the point, yes. See how maybe the syntax isn't the important thing here?
- dgb23 4y ago
  It's syntax that is optimized for expressions rather than statements. There are a lot of nice features falling out of that. In my opinion it makes little sense to misuse it in order to show its utility. It's a little bit like quoting someone out of context if that makes sense.
  - kerkeslager 4y ago
    > It's syntax that is optimized for expressions rather than statements. I'm not sure how you think S-expressions are any more optimized for expressions than, for example, infix notation. That's exactly what I'm showing with the second example. I'm open to hearing why you think S-expressions are better for expressions, but I suspect any differences you might point out are pretty subjective. > There are a lot of nice features falling out of that. Really I can only identify one feature which falls out of S-expressions, which can't be obtained with other syntaxes: macros. And whether that's a good feature is pretty subjective: it's pretty arguably a misfeature in my experience. > In my opinion it makes little sense to misuse it in order to show its utility. Agreed: I'm not misusing S-expressions to show their utility. I'm misusing S-expressions to show that they don't inherently give you the benefits of Lisp. And I'm showing Lisp-y code without S-expressions to show how the benefits of Lisp can be obtained without S-expressions.
    - lispm 4y ago
      > I'm not sure how you think S-expressions are any more optimized for expressions than, for example, infix notation. They aren't. But they are optimized to represent expressions as simple data: nested lists. One could write infix expressions as a data structure: (a + b * (c + d) * 3) READ converts it into a list. For that one could write a simple evaluator, a simplifier, or other tools based on simple list processing. > Really I can only identify one feature which falls out of S-expressions, which can't be obtained with other syntaxes: macros. Macros are one application of processing of s-expressions. The more general feature is representing any type of code as nested lists -> symbolic expressions. They are a compromise between a human-readable, textual & internal data format and machine processable code. Lisp code is just one application of that. It could be Prolog code, expressions of a theorem prover, or anything else which sports a custom processing engine and a lean way to input/process/output code as data. Actually macros can be obtained with other syntaxes. The Lisp way to represent code externally and internally as s-expressions is just one way. It's relatively simple and primitive. A simple interpreter for Lisp code can be written in a page of Lisp -> processing engines can also be very simple. The input and output of code then already provided by the reader and printer of s-expressions. Thus one can use s-expressions to design notations that are BOTH trivially a data structure with a textual representation AND processable with a simple predefined 'list processor' (aka Lisp) or any other custom "list processor". Looking at the textual representation in isolation is missing the bigger picture: it's the simple textual representation of lists AND a simple "list processor".

by dgb23 4y ago

kerkeslager 4y ago

> Your example is actually kind of misleading, because the second variation is much closer to how you write in a Lisp than the first. That's the point, yes. See how maybe the syntax isn't the important thing here?

dgb23 4y ago
It's syntax that is optimized for expressions rather than statements. There are a lot of nice features falling out of that. In my opinion it makes little sense to misuse it in order to show its utility. It's a little bit like quoting someone out of context if that makes sense.
- kerkeslager 4y ago
  > It's syntax that is optimized for expressions rather than statements. I'm not sure how you think S-expressions are any more optimized for expressions than, for example, infix notation. That's exactly what I'm showing with the second example. I'm open to hearing why you think S-expressions are better for expressions, but I suspect any differences you might point out are pretty subjective. > There are a lot of nice features falling out of that. Really I can only identify one feature which falls out of S-expressions, which can't be obtained with other syntaxes: macros. And whether that's a good feature is pretty subjective: it's pretty arguably a misfeature in my experience. > In my opinion it makes little sense to misuse it in order to show its utility. Agreed: I'm not misusing S-expressions to show their utility. I'm misusing S-expressions to show that they don't inherently give you the benefits of Lisp. And I'm showing Lisp-y code without S-expressions to show how the benefits of Lisp can be obtained without S-expressions.
  - lispm 4y ago
    > I'm not sure how you think S-expressions are any more optimized for expressions than, for example, infix notation. They aren't. But they are optimized to represent expressions as simple data: nested lists. One could write infix expressions as a data structure: (a + b * (c + d) * 3) READ converts it into a list. For that one could write a simple evaluator, a simplifier, or other tools based on simple list processing. > Really I can only identify one feature which falls out of S-expressions, which can't be obtained with other syntaxes: macros. Macros are one application of processing of s-expressions. The more general feature is representing any type of code as nested lists -> symbolic expressions. They are a compromise between a human-readable, textual & internal data format and machine processable code. Lisp code is just one application of that. It could be Prolog code, expressions of a theorem prover, or anything else which sports a custom processing engine and a lean way to input/process/output code as data. Actually macros can be obtained with other syntaxes. The Lisp way to represent code externally and internally as s-expressions is just one way. It's relatively simple and primitive. A simple interpreter for Lisp code can be written in a page of Lisp -> processing engines can also be very simple. The input and output of code then already provided by the reader and printer of s-expressions. Thus one can use s-expressions to design notations that are BOTH trivially a data structure with a textual representation AND processable with a simple predefined 'list processor' (aka Lisp) or any other custom "list processor". Looking at the textual representation in isolation is missing the bigger picture: it's the simple textual representation of lists AND a simple "list processor".