4 ms·

> humans can’t immediately parse structure with a glance, and sometimes we have to count parentheses by hand. This is why automatic indentation is important wh

> humans can’t immediately parse structure with a glance, and sometimes we have to count parentheses by hand. This is why automatic indentation is important when working with Lisp. This is mentioned later in the article, but I consider it mandatory because of the multitude of problem this approach resolves. For example, upon pasting the below snippet into emacs: (let* ((foo 10) (bar (+ foo 32)) (* foo bar)) The editor 1) notifies me that there is a missing paren somewhere, 2) automatically* reindents this code into: (let* ((foo 10) (bar (+ foo 32)) (* foo bar)) At this moment, it's obvious that we have three variable bindings, one of them malformed, and the programmer can correct this by planting a missing paren in the proper place. I wrote about this topic at length in https://mov.im/blog/phoe%40movim.eu/cd3577f6-fb1d-45f5-b881-7b9a68ee822e https://mov.im/blog/phoe%40movim.eu/cd3577f6-fb1d-45f5-b881-... before. * with aggressive-indent and electric-indent enabled in emacs, as soon as the missing paren is placed at the end

bloopernova 3y ago
Aren't there 11 parentheses in both of your code snippets? I must be missing something, sorry could you possibly explain where the missing parenthesis should be?
- taeric 3y ago
  It helps to basically vocalize what the code is doing. It is a "let" form, which has a list of variables, and then a body section using them. (It is a "let*", which also means that the variables can refer to variables that come before them, but not too relevant here.) To that end, the first () in a "let" should be of the forms (name value), where value can be a longer form, if needed. To that end, the last (name value) in the list should almost always look like (name value)), as it is closing the first in the list, that is ((name value).
- lelandbatey 3y ago
  They're not saying that the second snippet is "fixed", they're saying that the auto-indented second snippet highlights the mistake to the reader. Yes there are 11 parentheses in both the code snippets because both are "incorrect" in that they're both missing a parenthesis. The GP is trying to point out that since Emacs automatically re-indents the first snippet so that it looks like the second snippet, the reader knows immediately that something "isn't quite right".
  - bloopernova 3y ago
    Ahhh, understood. Thank you!
- phoe-krk 3y ago
  (let* ((foo 10) (bar (+ foo 32))) (* foo bar)) Or, to demonstrate the ugly "nailclip" style: (let* ((foo 10) (bar (+ foo 32))) (* foo bar) ) Note that I moved a closing paren off the third line and onto the second one, to close the variable bindings in the LET* form.
  - bloopernova 3y ago
    That explains it, thank you!
elwell 3y ago
And for that added flair, don't forget: https://www.emacswiki.org/emacs/RainbowDelimiters https://www.emacswiki.org/emacs/RainbowDelimiters.
adrian_b 3y ago
Automatic indentation helps, but the main problem is that LISP uses a single kind of parentheses in all places where some kind of brackets is required. If different kinds of brackets had been used for every distinct purpose, then there would have been no need to count parentheses or be dependent on enforcing invariable indentation rules. ALGOL 68 is another example of programming language with fully parenthesized non-ambiguous syntax, but it uses many kinds of different bracket pairs, which makes it much easier to read. While some of its bracket pairs, like if/fi, do/od, case/esac, have been rightfully mocked, they achieve well their purpose. In a programming language there are many different purposes for which bracket pairs are needed, e.g. for delimiting sub-expressions in order to change the default order of evaluation, for delimiting function argument lists, for delimiting array index lists, for delimiting blocks, for delimiting function bodies, for delimiting record/structure component definitions, for delimiting the components of various program structures, like conditional expressions and loops, and so on. For an automatic parser, the use of different kinds of brackets can only make its task easier, never harder, because in the worst case its lexical analysis could replace all kinds of brackets with a single kind, while for a human reader different kinds of brackets are always helpful. Using many kinds of bracket pairs is not necessarily as verbose as in Algol 68, because Unicode offers enough bracket pairs to choose for all purposes. In LISP all parentheses look the same, but a LISP programmer who does not recognize that the things delimited in those parentheses are of different natures, e.g. "(CAR ..." vs. "(COND ..." vs. "(QUOTE ..." and so on, cannot write high quality LISP programs. Many years ago, I have written many rather big Scheme or LISP programs, because they have many advantages beyond the uniform parentheses. If I would use again a language of the LISP family, I would use a text preprocessor to pass the source to the compiler, which would allow me to use various kinds of bracket pairs, for instance Unicode mathematical angle brackets for COND, Unicode bag delimiters for loops, curly brackets for blocks (curly bracket is the Unicode term for braces), and so on.
- alexisread 3y ago
  I've often wondered if it was worth a language having interchangeable brackets that you could use similar to 4-colour problems eg. ([1 2] 3) is the same as {[1 2] 3} or ((1 2) 3) semantically, just visually easier to read. Any takers?
jacknews 3y ago
Yes, this is my argument against significant-whitespace languages like python, or even worse for simple nested data like yaml. Actual delimiters explicitly structure your code, and then automatic formatting confirms it, kind of like double-entry book-keeping. For me, just a couple of days with lisp and parentheses made me wish every language had such simple explicit syntax, I really recoil at some language's special syntax, eg python list comprehension. Maybe I just hate python, lol.
somewhereoutth 3y ago
~ let* ~ ~ foo 10 ~ bar (+ foo 32) ~ * foo bar

bloopernova 3y ago

Aren't there 11 parentheses in both of your code snippets? I must be missing something, sorry could you possibly explain where the missing parenthesis should be?

taeric 3y ago
It helps to basically vocalize what the code is doing. It is a "let" form, which has a list of variables, and then a body section using them. (It is a "let*", which also means that the variables can refer to variables that come before them, but not too relevant here.) To that end, the first () in a "let" should be of the forms (name value), where value can be a longer form, if needed. To that end, the last (name value) in the list should almost always look like (name value)), as it is closing the first in the list, that is ((name value).
lelandbatey 3y ago
They're not saying that the second snippet is "fixed", they're saying that the auto-indented second snippet highlights the mistake to the reader. Yes there are 11 parentheses in both the code snippets because both are "incorrect" in that they're both missing a parenthesis. The GP is trying to point out that since Emacs automatically re-indents the first snippet so that it looks like the second snippet, the reader knows immediately that something "isn't quite right".
- bloopernova 3y ago
  Ahhh, understood. Thank you!
phoe-krk 3y ago
(let* ((foo 10) (bar (+ foo 32))) (* foo bar)) Or, to demonstrate the ugly "nailclip" style: (let* ((foo 10) (bar (+ foo 32))) (* foo bar) ) Note that I moved a closing paren off the third line and onto the second one, to close the variable bindings in the LET* form.
- bloopernova 3y ago
  That explains it, thank you!

elwell 3y ago

And for that added flair, don't forget: https://www.emacswiki.org/emacs/RainbowDelimiters https://www.emacswiki.org/emacs/RainbowDelimiters.

adrian_b 3y ago

Automatic indentation helps, but the main problem is that LISP uses a single kind of parentheses in all places where some kind of brackets is required. If different kinds of brackets had been used for every distinct purpose, then there would have been no need to count parentheses or be dependent on enforcing invariable indentation rules. ALGOL 68 is another example of programming language with fully parenthesized non-ambiguous syntax, but it uses many kinds of different bracket pairs, which makes it much easier to read. While some of its bracket pairs, like if/fi, do/od, case/esac, have been rightfully mocked, they achieve well their purpose. In a programming language there are many different purposes for which bracket pairs are needed, e.g. for delimiting sub-expressions in order to change the default order of evaluation, for delimiting function argument lists, for delimiting array index lists, for delimiting blocks, for delimiting function bodies, for delimiting record/structure component definitions, for delimiting the components of various program structures, like conditional expressions and loops, and so on. For an automatic parser, the use of different kinds of brackets can only make its task easier, never harder, because in the worst case its lexical analysis could replace all kinds of brackets with a single kind, while for a human reader different kinds of brackets are always helpful. Using many kinds of bracket pairs is not necessarily as verbose as in Algol 68, because Unicode offers enough bracket pairs to choose for all purposes. In LISP all parentheses look the same, but a LISP programmer who does not recognize that the things delimited in those parentheses are of different natures, e.g. "(CAR ..." vs. "(COND ..." vs. "(QUOTE ..." and so on, cannot write high quality LISP programs. Many years ago, I have written many rather big Scheme or LISP programs, because they have many advantages beyond the uniform parentheses. If I would use again a language of the LISP family, I would use a text preprocessor to pass the source to the compiler, which would allow me to use various kinds of bracket pairs, for instance Unicode mathematical angle brackets for COND, Unicode bag delimiters for loops, curly brackets for blocks (curly bracket is the Unicode term for braces), and so on.

alexisread 3y ago
I've often wondered if it was worth a language having interchangeable brackets that you could use similar to 4-colour problems eg. ([1 2] 3) is the same as {[1 2] 3} or ((1 2) 3) semantically, just visually easier to read. Any takers?

jacknews 3y ago

Yes, this is my argument against significant-whitespace languages like python, or even worse for simple nested data like yaml. Actual delimiters explicitly structure your code, and then automatic formatting confirms it, kind of like double-entry book-keeping. For me, just a couple of days with lisp and parentheses made me wish every language had such simple explicit syntax, I really recoil at some language's special syntax, eg python list comprehension. Maybe I just hate python, lol.

somewhereoutth 3y ago

~ let* ~ ~ foo 10 ~ bar (+ foo 32) ~ * foo bar