Live data from Hacker News

An Intuition for Lisp Syntax

stopa.io

31–40 of 201 posts

Re: An Intuition for Lisp Syntax

#31
post #16

So what does Lisp make harder to implement than today's programming languages? 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 projec…

> Performance has historically been an issue for Lisp because its model is tightly tied to interpretation

That hasn't been true since 1962.

Re: An Intuition for Lisp Syntax

#32
post #15

A simpler intuition. Opening parenthesis moves to the left, whitespace acts as colon. So, f(a, b, c) becomes (f a b c).

This isn’t the right intuition for the syntax, this is the right intuition for evaluation. 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.

For someone who hasn't used sexprs or looked at an AST before, it might not be clear why a data structure and atomic elements are goals in the first place.

I tried to write an explanation but found it surprisingly difficult to articulate. In short, there's almost certainly other ways to accomplish the same thing but sexprs are dead simple and they work _really_ well in practice. Just go use them and it will make sense!

Re: An Intuition for Lisp Syntax

#33
post #17

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'.

From what I understand, this relates closely to the "Lisp Curse"

[deleted]

Re: An Intuition for Lisp Syntax

#34
This is maybe the best introductions to Lisp i have seen, especially for a js dev like me it could hardly get more approachable and convincing.

I could not help but thinking at the end, this is really awesome but s-expressions are kind of hard to read and reason about for my brain, it would be cool if we could generate them from more readable syntax, maybe something like javascript :D . Unfortunately the standard js AST seems to be not a great fit but i found a S-Expression encoder for js AST https://github.com/anko/eslisp

This way instead of having to write s-expressions manually we took a whole circle and are back at js but with macros, not relying on eval and having a code is data representation...

Re: An Intuition for Lisp Syntax

#37
post #16

So what does Lisp make harder to implement than today's programming languages? 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 projec…

> a well-structured way to define and enforce APIs

I don't see the issue here? What do you think is stopping you from doing this in, for example, Common Lisp?

> and oh wow, typing facilities

Common Lisp isn't typed, but there's no reason a Lisp dialect can't be. In fact, Typed Racket is just such a language.

Re: An Intuition for Lisp Syntax

#38
post #10

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?

[deleted]

Re: An Intuition for Lisp Syntax

#39
post #10

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?

Have a look at Clojure Spec. The other one, which I don't like much, is PHP. For me it's strange that nobody seems to talk about the power of PHP map-like data structure and it's upsides because it is the main data structure.
Post reply on HN