<story><title>Parinfer – Simpler Lisp Editing</title><url>https://shaunlebron.github.io/parinfer/</url></story><parent_chain><item><author>modernerd</author><text>I loved using Parinfer when I was writing ClojureScript, but it also made me question the value of Lisp syntax.&lt;p&gt;If brackets can be inferred from indentation, doesn&amp;#x27;t this imply that they&amp;#x27;re extraneous — that indentation only would be sufficient to write many Lisp structures?</text></item></parent_chain><comment><author>lispm</author><text>One can do that, but most Lisp programmers value the direct &amp;quot;source code is data&amp;quot; nature of Lisp - using s-expressions.&lt;p&gt;Alternative notations were originally planned for Lisp when it was designed - some books were published using it, but for actual programming it wasn&amp;#x27;t used too much - especially since most implementations actually a) didn&amp;#x27;t support it or b) had s-expressions as a default&amp;#x2F;internally.&lt;p&gt;Then several attempts to modernize Lisp with a different syntax mostly failed to get traction or failed big (like the Lisp 2 effort).&lt;p&gt;Then some efforts failed to provide more than one syntax and also failed to appeal to people (Dylan).&lt;p&gt;What we saw is a bunch of languages derived from Lisp with different syntax (ML, Logo, ...) and a bunch of Lisps for mathematics with different syntax (Reduce, Macsyma, ...).&lt;p&gt;But the core Lisp programmers were never willing to give up the s-expression-based syntax. It has some clear advantages when manipulating code, especially in interactive programming.</text></comment>
<story><title>Parinfer – Simpler Lisp Editing</title><url>https://shaunlebron.github.io/parinfer/</url></story><parent_chain><item><author>modernerd</author><text>I loved using Parinfer when I was writing ClojureScript, but it also made me question the value of Lisp syntax.&lt;p&gt;If brackets can be inferred from indentation, doesn&amp;#x27;t this imply that they&amp;#x27;re extraneous — that indentation only would be sufficient to write many Lisp structures?</text></item></parent_chain><comment><author>kazinator</author><text>&amp;gt; &lt;i&gt;If brackets can be inferred from indentation, doesn&amp;#x27;t this imply that they&amp;#x27;re extraneous.&lt;/i&gt;&lt;p&gt;Yes; this deduction is valid.&lt;p&gt;However, can brackets be inferred from indentation.&lt;p&gt;Let&amp;#x27;s start with a trivial case:&lt;p&gt;&lt;pre&gt;&lt;code&gt;   [indent]15
&lt;/code&gt;&lt;/pre&gt;
Is this object 15? (15)? Or ((15))? How do we apply indentation to distinguish them?&lt;p&gt;Do we count the spaces? Indentation is two-space so that 15 preceded by no extra indentation relative to the current level is just 15, then 15 preceded by two space is (15), and so on?&lt;p&gt;And is that really going to be readable?&lt;p&gt;What if there is whitespace?&lt;p&gt;&lt;pre&gt;&lt;code&gt;    material material
    
    ;; .. vertical break

      15   ;; this is (15) but could be 15 if I don&amp;#x27;t  see the preceding material.
&lt;/code&gt;&lt;/pre&gt;
There is ambiguity in indentation. If I see this:&lt;p&gt;&lt;pre&gt;&lt;code&gt;   (1 2 3
    4 5 6
&lt;/code&gt;&lt;/pre&gt;
where 4 5 6 is the last line in  my edit window, I know that this list is not well-formed: zero or more items must follow, and then a closing parenthesis.  If indentation is used, I have no idea: I could be looking at the complete thing.</text></comment>