Hacker News new | past | comments | ask | show | jobs | submit login

Lisp Programmers: "You guys are still trying to figure out parsing?"

On a more serious note, the grammar ambiguity mentioned in the article is one of the things that has drawn me to languages that use s-expressions. Lisp are just as varied in their semantics as any other set of languages. What sets them apart is in their shared syntactic core of prefix notation in combination with parenthesis to create s-expressions. This eliminates the vast majority (though not all) ambiguities concerning precedence and associativity.




While I appreciate the benefits of Lisp, there is still a tradeoff. PG said in one of his essays that in Lisp you write your program directly in the parse trees that in other languages get generated when the code is parsed. But that means that in Lisp you have to express everything in terms of parse trees, and parse trees can be cumbersome. That's why other languages have syntax; yes, in a way it's just syntactic sugar for parse trees, but syntactic sugar has uses.


It seems more like you hardly ever write parse trees directly in Lisp. Instead you write macros that get expanded into them.

It’s not really parsed until you have a data structure that lets you search for all occurrences of a special form. Using lists for everything ignores important distinctions between levels.


Macros are parse trees, which define code that operates on other parse trees to expand them into still other parse trees. The ability to operate directly on parse trees and transform them into other parse trees is a key advantage of writing parse trees directly instead of having a layer of syntax in between.


Yeah, they're the ultimate 'syntactic sugar'. They take a bit of time to wrap your brain around, but it's much easier to figure out what a macro is doing under the hood than it is to figure out that exact semantics of syntactic sugars in other languages. I try not to use them as much as I can, but for a certain subset of problems there's nothing better for eliminating repetitive code and for taking the language semantics out of the foreground so that you're just left with your application semantics.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: