Comment by kerkeslager
3 years 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?
3 years 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?
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.
> 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.
> 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".