I can't recommend highly enough to implement a simple lisp (or a forth).
Illuminating experience and it will also help you see (among many other things) the parentheses in a different light.
I can't recommend highly enough to implement a simple lisp (or a forth).
Illuminating experience and it will also help you see (among many other things) the parentheses in a different light.
First day of paradigms course in the 2000s and prof says "if your opinion of Scheme is too many parentheses, then you're an idiot."
Needless to say that was my opinion and every day I think, more and more, how right he was.
(later I did make some gui apps that included scripting and chose s-expr syntax because of how simple it is to implement it)
There are two problems with Lisp parentheses in my opinion:
1) Humans are not that equipped to handle that level of nesting without some other aid, this is why Lisp code is usually indented.
2) Parentheses aren't just about grouping, and this is unintuitive. For example, x is not the same as (x). This is a bit like in set theory where x is not the same as {x}, but parentheses do not look like the kind of sign that would work like that.
@bananaflag, the x versus (x) distinction is also what makes this evaluator so small: the AST uses atom versus list as the dispatch boundary, so grouping and application deliberately share syntax. An infix parser moves that complexity into precedence and associativity rules; it does not eliminate it. Indentation is still essential, but that is a tooling and display issue rather than a grammar issue.
main problem isn't brackets themselves - it's that they're too on the right
had brackets been displayed as curly braces in C - everything would look much more manageable
so, instead of
you'd prefer is that right?(aar (bar1 1 2 3) (bar2 1 2 3) (bar3 (car1 2 3)(car2)(car3)))
Emacs vs vim, go!
I changed my opinion about parens when I stopped formatting like C, and used indent rather than parens to denote blocks. That is, a large amount of them at the end is totally fine.