Every time somebody proposes to "fix" Lisp's syntax it reminds me of that scene. It sounds like a newbie Lisp programmer who hasn't yet experienced the thrill of seeing beyond the parentheses. And the mind-boggling compositional utility that comes from leaving them alone.
if 1:
<tab>if 0:
<tab><tab>print(1)
<spaces*n>print(2)
f(a b) == (f a b)
{a f b} == (f a b)
With good tooling this is not a problem. Try the demos here: http://treenotation.org/sandbox/build/. Make some indentation errors. It's very hard to ignore all the help the editor gives you.
> And elegant composition is impossible with infix notation unless -- you add parens again.
This is a valid criticism. I've seen some folks working on this though, and I expect we'll see a new elegant solution.
>> And elegant composition is impossible with infix notation unless -- you add parens again.
> This is a valid criticism.
I was thinking of "elegant composition" of subexpressions. Or, in other words, inline Trees/S-Expressions.
You'll note that most code people write in almost any language is prefix anyway. `foo(bar, baz)` isn't infix; it's prefix with the operator placed to the left of the paren.
Is elegant composition possible with prefix notation and some whitespace and indentation instead of parentheses everywhere?
I think it might be.
I parse Lisp similar ways and speed as Python. The indentation in Lisp code is works the the same way.
Q: How can you tell when you've reached Lisp Enlightenment?
A: The parentheses disappear.
–– Anonymous They are disturbing only people who don't program with Lisp a lot.
BTW, this post was an outcrop of another article "Why Lisp Failed (2010)" https://news.ycombinator.com/item?id=20374782
Agreed! For decades some people have said parens in S-Expressions are useless.
But a key thing we're pushing, that's never been pushed before, is that the parens are worse than useless--they are harmful! They prevent easier program concatenation and ad hoc parser writing. And they make program synthesis, visual programming, and code analysis ~10x harder, for next to no gain.
I'm hoping we'll start to turn the tide and bring the 99.9% of the population into the Tree Notation world, and those LISPers that love their parens can remain happily in their (world).
Almost everything you've said above is not just untrue, but the opposite of the truth. As such, your statements require supporting evidence. Please cite some.
And who, by the way, is "we"?
There is also a big open source release coming soon—the largest database of programming languages and features in the world by a factor of at least 10x, more like 100x. Over 10k languages, over 1k columns.
We is the Tree Notation Lab. Will be announcing what that is and the funding for it later this month.
This assertion is patently false. Parens make it quite trivial to parse and render the underlying tree structuee rather obvious. Concatenating programs is just a matter of splicing a subtree into the target tree.
Here's a proof.
- In S-Expressions with parens, there are infinite ways to write any given abstract syntax tree.
- In Tree Notation, there is only 1 way to write any given abstract syntax tree.
If you change one letter, you get a different tree.
- Say I wrote programs in a Tree Language with a root node called "dumpToConsole" and I want to
rename all such nodes to "print". I can write a type-safe ad hoc parser that does
a simple search replace "/\ndumpToConsole/print/",
using Tree Notation. If it were in S-Expressions, I'd have to use a full parser.There is no need to change Lisp into different language because they already exist. Trying to get people who don't want to learn Lisp to learn Lisp is pointless.
It is the unambiguous notation enabled by the parentheses that allow lisp to process code as data and construct programs on the fly.
IMHO, those who suggest eliminating the parentheses don't yet understand lisp. Trying to make lisp more widely acceptable by eliminating them is throwing the baby out with the bathwater.
IMHO, those who suggest eliminating the parentheses don't yet understand lisp.
f(a b) == (f a b)
{a f b} == (f a b)
f
a b ≛ (f (a b))Objectively:
1. I can't look at a line and tell if I have a complete expression. I must look at the following line and compare its indention level to this line. I may also need to look at the previous line(s) to see if we've switched to infix unexpectedly.
2. Indention means your programs will be bigger in physical area (meaning more scrolling).
Pragmatically:
3. People are unable to reliably copy/paste indention-languages into many web forums (like HN and Reddit) making it harder for them to get the help they need when starting out.
4. It's slower and more complex to parse, making build/compile times slower.
Subjectively: It just looks worse.
Autoindent and paren matching is currently a basic feature of virtually all mainstream text editors. Therefore, picking up any random mainstream text editor is already enough to address your concerns.
Without that, why am I using Lisp? If I just want a reasonably high-level language but don't care about macros (or other features that rely on seeing the actual structure clearly), why wouldn't I just use Ruby/Python/Smalltalk? They're pretty good, too.
I can almost guarantee it's going to be more pleasant, down the road, using one of those languages as it's intended to be used, rather than trying to contort Lisp this way. Getting an answer to a Lisp question on StackOverflow is hard enough with standard syntax. No Lisp programmer is going to want to help with a program written like this.