Hacker News Reader

Comment by neokantian | Hacker News Reader

As I see it, Lisp is a language in (pretty much) pure prefix notation and of which the core data structure is a linked list and in which functions are first-class values. The advantages of the prefix notational purity are manifold, but schools train people in the use of infix/Eulerian notation:

f(a+b,g(x,y)) versus (f (+ a b) (g x y))

The problem of notational convention has not been solved since 1958. Other languages painstakingly support infix/Euler, requiring comparatively incredible compiler construction effort. Doing so also removes the manifold advantages of Lisp's notational purity.

JSON is much more popular than S-expressions. Therefore, we can assume that nested arraylist/hashtables are more popular than linked lists as the core language data structure.

Pretty much every serious language treats functions as first-class values nowadays. So, this is no longer a strategic advantage in Lisp.

View on HN

"Other languages painstakingly support infix/Euler, requiring comparatively incredible compiler construction effort"

Shunting-yard is trivial. What painstaking, incredible compiler construction do you refer to?

Shunting-yard has an incredible validation problem. It works until you hit errors in the expression, and you need to output meaningful error messages. Even LL(1) reacts more gracefully to errors. I think that this is the main reason why Dijkstra's shunting-yard is not used in any serious scripting engine or compiler.

> incredible compiler construction effort

Not really. BYTE magazine, in the 1970s, published the complete source code for a Pascal compiler, including the code generator.

Pascal can undoubtedly be shoehorned into the target of a simple, single-pass LL(1) parser. Doing so comes at a real "flexibility" cost, though. For example, don't try to define your functions in any arbitrary order. It won't fly. As a programmer, you will surely notice the limitations of single-pass LL(1) compilers. Nowadays, infix/Eulerian notations are generally targeted with at least an LALR(1) parser. The notational complexity in languages like C++ (in gcc) and C# generally even exceed what LALR(1) can handle. Apparently, their parsers need to be painstakingly hand-coded. In my book, that is clearly overshoot. Do we really need to create a dependency on languages that even LALR(1) cannot handle? What are you even getting in exchange? Debatable ...

Those are all valid points, but not relevant to infix vs prefix notation.

I don't know about C#, but parsing C++ is complex because you need a symbol table to do it.

D doesn't need a symbol table to parse, but it does require arbitrary lookahead. It still isn't hard to parse, and the parser fits in one file:

https://github.com/dlang/dmd/blob/master/src/dmd/parse.d

Is this the issue you are referring (?):

https://archive.org/details/byte-magazine-1978-09

yes

What are the top benefits to the programmer to this alternative notation? Generally readability issues don't come from the visual burden of separating keywords, names and data.

I think you missed out symbols. That's a big part of Lisp programming and sorely missed in other languages.

But again, no longer unique to lisp - Ruby for example deeply integrates them as do Clojure, Elixir, and others.

Clojure is Lisp. In any case it's not just having one or two features from Lisp, every language has that, it's about the combination of those features.

Reply on news.ycombinator.com