11–20 of 201 posts
I've never really bothered to learn lisp, but this is incredible. I get it now. That being said, I wonder how data types would work as opposed to lists. What would a language based around maps look like?
[sendMessage with:arg1 to:arg2]
IMO, by far the most confusing thing about lisp syntax is not code data duality, but instead that when you actually dive into the specs for these languages, its actually still really complicated and full of edge cases. A "toy" lisp can be simple sure, but "real" lisps aren't.
The formal Scheme syntax spec is, what?, a few pages. Far smaller than any other "real" language I'm aware.
I've never really bothered to learn lisp, but this is incredible. I get it now. That being said, I wonder how data types would work as opposed to lists. What would a language based around maps look like?
It would look like smalltalk: [sendMessage with:arg1 to:arg2]
I've never really bothered to learn lisp, but this is incredible. I get it now. That being said, I wonder how data types would work as opposed to lists. What would a language based around maps look like?
So, f(a, b, c) becomes (f a b c).
It seems like large-scale composition relies on a well-structured way to define and enforce APIs, and oh wow, typing facilities.
Performance has historically been an issue for Lisp because its model is tightly tied to interpretation, but perhaps modern JIT-style compilation can address this.
Others?
What type of issues do large Lisp projects typically run into?
The unless example is a good one. So while you can trivially implement 'unless' in lisp, most probably in a large code base, you'll en up with 'unless', 'if-not' and depending on how creative others are probably also 'negat-if'.
A simpler intuition. Opening parenthesis moves to the left, whitespace acts as colon. So, f(a, b, c) becomes (f a b c).
Why move that bracket? The answer is simple: we want the syntax to also denote a serialized data structure: a tree of atomic elements.
So (f a b c) represents a list of symbols F, A, B, C, and the interpretation of this list is a call of the function F on arguments A, B, C.
I get the code is data thing, but I don't really find it that much useful. And there is a good reason most languages don't allow it - other people :) The unless example is a good one. So while you can trivially implement 'unless' in lisp, most probably in a large code base, you'll en up with 'unless', 'if-not' and depending on how creative others are probably also 'negat-if'.
IMO, by far the most confusing thing about lisp syntax is not code data duality, but instead that when you actually dive into the specs for these languages, its actually still really complicated and full of edge cases. A "toy" lisp can be simple sure, but "real" lisps aren't.
The formal Scheme syntax spec is, what?, a few pages. Far smaller than any other "real" language I'm aware.
Also compare https://people.csail.mit.edu/jaffer/r5rs_9.html and e.g. https://docs.python.org/3/reference/grammar.html which I would consider a relatively syntactically rich language.