3 ms·

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

by 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

> 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".