5 ms·
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-cla
by neokantian 8y ago
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.
- WalterBright 8y ago> incredible compiler construction effort Not really. BYTE magazine, in the 1970s, published the complete source code for a Pascal compiler, including the code generator.
- neokantian 8y agoPascal 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 ...
- deleted 8y ago[deleted]
- WalterBright 8y agoThose 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 https://github.com/dlang/dmd/blob/master/src/dmd/parse.d
- fsloth 8y agoIs this the issue you are referring (?): https://archive.org/details/byte-magazine-1978-09 https://archive.org/details/byte-magazine-1978-09
- WalterBright 8y agoyes
- another-cuppa 8y agoI think you missed out symbols. That's a big part of Lisp programming and sorely missed in other languages.
- aaron-lebo 8y agoBut again, no longer unique to lisp - Ruby for example deeply integrates them as do Clojure, Elixir, and others.
- another-cuppa 8y agoClojure 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.
- cameronh90 8y ago"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?
- neokantian 8y agoShunting-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.
- threatofrain 8y agoWhat 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.