Ask HN: Why do people say "Lisp has no syntax"? It has infinite syntax
The author discusses Lisp's syntax, highlighting its list-based structure and challenges with constructs like `cond`. They conclude that Lisp's complexity resembles other languages, despite its unique features.
The author reflects on the common belief that Lisp has no syntax, suggesting instead that its syntax is based on list expressions where the first element is a function and the rest are arguments. They describe their experience creating a Lisp-like language, initially using recursive descent parsing to interpret expressions. This method works well for basic function calls but raises challenges when introducing conditionals, such as the `cond` construct. The author notes that treating `cond` as a function is problematic because it does not behave consistently with the function definition; it evaluates conditions until one is true, which can lead to the same output for different inputs. This realization leads to the conclusion that while Lisp has a uniform structure of list expressions, the internal rules governing those expressions are varied and complex. The introduction of macros and reader macros further complicates the syntax, allowing for a broader range of expressions beyond simple list structures. Ultimately, the author feels that this understanding diminishes the perceived uniqueness of Lisp, likening it to other programming languages with multiple syntax rules. They express a continued appreciation for Lisp but acknowledge that practical computation requires deviating from the simple (function args) syntax, suggesting that only a pure lambda calculus could maintain such uniformity.
Related
I Probably Hate Writing Code in Your Favorite Language
The author critiques popular programming languages like Python and Java, favoring Elixir and Haskell for immutability and functional programming benefits. They emphasize personal language preferences for hobby projects, not sparking conflict.
How the Curse of Lisp impacts your business (even if you don't use Lisp)
The Curse of Lisp highlights how languages like Lisp's self-sufficiency can hinder growth by limiting external contributions and fostering insular development practices. Balancing internal efficiency with external innovation is crucial for sustainable system design.
Tonsky: Don't go crazy with Clojure unless it makes you happy
The author shares their journey using Clojure macros for Humble UI's component library, emphasizing the language's flexibility in enabling unconventional solutions like reading source files and fetching code seamlessly.
"Maxwell's equations of software" examined
Ken Shirriff's blog post analyzes a historic Lisp code snippet, showcasing Lisp's core principles. It highlights code-data interchangeability and the essence of Lisp programming, referencing Alan Kay's "Maxwell's Equations of Software."
Clojure macros continue to surprise me
The author shares their journey using Clojure macros for Humble UI's component library, creating a macro to display running code alongside its source. Despite challenges, they find Clojure's flexibility rewarding for experimentation.
`cond` still returns the same output even though its input args
have changed. So `cond` is not a function anymore!
It sounds like you're holding the definition of "pure function" backwards: a pure function can't give a different OUTPUT for the same INPUT.A feature like "cond" is usually implemented as a macro (since the arguments are only evaluated sometimes) but that's ultimately just a shorthand for a bunch of extra "quote" wrapping.
That's wrong. Lisp has functions, special operators (like IF) and macros. Also any data-object is also valid Lisp.
Valid Lisp examples:
3 -> number
"string" ->
hello -> variable
(print "hello world") -> function call
special forms (if (> a 10) 1 0) -> no more than three args,
arg 2 & 3 are evaluated depending on first argument value
(let ((var1 20) -> definition of local variables
(var2 22))
(+ var1 var2))
(quote hello) -> definition of a literal object
macros (defun foo (arg1 arg2) -> defun is macro, which defines global functions
(if (> arg1 arg2)
1
0))
> But this means that `cond` is not a function anymore because it could be that for two different inputs, it returns the same output.A function can return the same output for different inputs.
(defun foo (args)
0)
Above returns 0 for all arguments. It's a valid function.> So essentially, my understanding so far is that Lisp has list expressions, but what goes on inside those expressions is not necessarily following one unifying syntax rule—it actually follows many rules. And things get more complicated when we throw macros in the mix: Now we have the ability to have literally any syntax within the confines of the list expressions, infinite syntax!
That's true.
Edit: What I am saying is that in lisp '(' is actually a command and everything after it is an argument to that command. The syntax is command - arguments; this is what gives these languages their power, the simple syntax and lack of grammar allows us to define our own grammar. Hopefully someone will correct me if I misunderstand, I could be seeing Tcl and Forth everywhere since I have been primarily working with them lately.
Related
I Probably Hate Writing Code in Your Favorite Language
The author critiques popular programming languages like Python and Java, favoring Elixir and Haskell for immutability and functional programming benefits. They emphasize personal language preferences for hobby projects, not sparking conflict.
How the Curse of Lisp impacts your business (even if you don't use Lisp)
The Curse of Lisp highlights how languages like Lisp's self-sufficiency can hinder growth by limiting external contributions and fostering insular development practices. Balancing internal efficiency with external innovation is crucial for sustainable system design.
Tonsky: Don't go crazy with Clojure unless it makes you happy
The author shares their journey using Clojure macros for Humble UI's component library, emphasizing the language's flexibility in enabling unconventional solutions like reading source files and fetching code seamlessly.
"Maxwell's equations of software" examined
Ken Shirriff's blog post analyzes a historic Lisp code snippet, showcasing Lisp's core principles. It highlights code-data interchangeability and the essence of Lisp programming, referencing Alan Kay's "Maxwell's Equations of Software."
Clojure macros continue to surprise me
The author shares their journey using Clojure macros for Humble UI's component library, creating a macro to display running code alongside its source. Despite challenges, they find Clojure's flexibility rewarding for experimentation.