Hacker News Reader

Comment by mruts | Hacker News Reader

No one actually likes the parens of Lisp. I mean, just look at Racket2. Even the dedicated lispers who work on Racket think they suck.

I’ve written both Racket and Common Lisp professionally and consider myself very competent in both. In fact, I think they’re both great languages and one of the best around.

It’s not because of the parens though, it’s because what the parens give you: namely homoiconicity and easy macros.

Without these things, the increased syntax burden of parens don’t buy you anything except visual noise and being forced to type extra characters.

View on HN

Your statement doesn't represent everyone. I thought that the design of Lisp was a great idea before I learned about its macros. (This was at a time twenty years ago when macros weren't being hyped in programming forums.) I was impressed that it simplified the specification of the language and the implementation of parsing, as well that it eliminated ambiguity. Then came the realization that formatting the code to look consistently good, no matter which way it is broken into multiple lines is trivial, and that it enables great editor support. Oh, and being able to just quote any chunk of the program as a datum!

Also:

Symbols tokens made up of almost any sequence of non-whitespace characters: if you type <->, that is a symbol without having to modify the lexical analyzer of the language to recognize a new token pattern.

Basic math operations being variadic:(+ term0 term1 term2 ...).

Here is an advantage of Lisp syntax: -123 is an actual negative integer token, and not the unary operator applied to 123, requiring evaluation.

S expressions bring a syntactic simplicity that makes code easier to read and more explicit

It also makes it easier to edit structurally.

So yes homoiconicity and easy macros are nice but please refrain from including me in your use of "no one"

And me :) - I love s-expressions.

> Without these things, the increased syntax burden of parens don’t buy you anything except visual noise and being forced to type extra characters

So instead of f(x), I have to accept the visual noise and extra characters of (f x)?

What's worse, instead of f(x, y); you have to accept the visual noise and extra characters of (f x y).

I don’t really understand these kind of arguments. Seasoned lispers use ‘ or #’ or a backtick or ,@ all the time. Or look at the CL loop macro. If I had to wrap every function in CL with (function ...) I would shoot myself. Same thing with quotes. Or, what about strings, or vectors? Strings have a special syntax, and no one complains about writing “foo”. You know why? Because it’s nice. This magical syntaxless world everyone wants to live in actually sucks big-time, even for Lispers.

If anyone really cared about parens, they wouldn’t be using (or creating) these kinds of things in the first place. I think it’s a pretty indefensible position to say that Lispers actually just like parens for the sake of them. If that was the case, why not start a form with (( or even (((?

Like, does anyone like using progn or begin? I mean seriously..

Syntax is great, DSL’s are great, they help you to express things elegantly and succinctly. This is my major beef with Lisp. If I’m not manipulating the AST, I don’t want the heavy syntax burden. If I am, then great, Lisp is awesome.

Maybe my career is different from you guys, but I’m not transforming source code even 5% of the time. I’m adding numbers, I’m multiplying stuff, I’m writing out formulas. And let me tell you, trying to write out math with S-exps majorly sucks. You would have to be insane to think that “(+ (fib (n - 1) (fib (n - 2)))” is better than “fib(n - 1) + fib(n - 2)”.

Sorry if this sounds like a rant (it kinda is), but I don’t think anyone thinks syntax is bad. It’s just that Lisp has minimal syntax and that seems good enough. You don’t notice all of the nice and convenient things you would have to give up if you actually had a completely regular syntax.

> Lisp has minimal syntax

It hasn't. It just works differently.

S-expressions define syntax for data: lists, strings, numbers, symbols, vectors, arrays, ... Plus a bunch of abbreviations (quote, function quote, ...) and some extras (templates, reader control, ...). One can program that part with reader macros.

Then Lisp usually has around three (or more) syntax classes for prefix forms:

1) function calls

2) special forms like LET, ...

3) macros like DEFUN, DEFCLASS, WITH-SLOTS, ...

Special operators and macro operators introduce syntax. See the Scheme manuals or the Common Lisp spec for the EBNF definitions of these syntax operators. This can be simple or relatively complex (LOOP macro would be an example, but also something like DEFSTRUCT, ...). The user can write macros to extend the syntax.

Now if we want infix/mixfix arithmetic, we can embed it via the reader

#i( fib(n - 1) + fib(n - 2) )

or as a macro:

(infix fib (n - 1) + fib (n - 2))

Problem: it's not built-in and not that common.

> I’m adding numbers...

Now one would have a bunch of options:

1) live with the Lisp syntax as it is, improve it where possible

2) use syntax extensions for mathematical code, may have tooling drawbacks

3) use a different surface syntax for Lisp or a specialized syntax (see Macsyma and similar)

4) use a different language with the usual mix of prefix, infix and postfix operators

Libs:

https://github.com/ruricolist/infix-math

https://www.cliki.net/infix

https://github.com/peey/ugly-tiny-infix-macro

https://github.com/rigetti/cmu-infix

http://readable.sourceforge.net

> So instead of f(x), I have to accept the visual noise and extra characters of (f x)?

(f x) and f(x) have the exact same number of characters; one mans'visual noise' is another's 'visual clarity'

What about (+ (/ 1 2) 5) and 1/2 + 5?

Also if you think parens and prefix notation are so great, would you also like to see math papers written that way?

I don't think it's a given that a useful way of expressing programs must also be a useful way of expressing an academic paper.

That being said, a lot of mathematical notation is pretty close to lisp syntax, basically anything that works like sigma.

I see what you mean: Math uses 2D notations with fixed positions. The space around an operator can be subdivided into nine sections (top, bottom, left, right, corners). That yields up to nine positions for operands. Fixed positions means, effectively, no precedence parsing, just like what S-exps do in one dimension. The operands themselves use spatial subdivision likewise. E.g:

      x
           z+w
  y   op   ---
           s+t

this would (op x y (/ (+ z w) (+ s t))).

Now you have to know that 1 / 2+5 is still (1/2) + 5.

The S-exp can be shortened in anything calling itself a Lisp, using the unary reciprocal: (+ (/ 2) 5).

Math papers are full of obscure notations; they should standardize on s-exps. Then just a straightforward dictionary of symbols would be needed to look up a notation.

Math notation is at least 2D: it makes good use of spatial structures to reduce ambiguity. For instance, instead of inventing some crazy ternary operator, mathematicians will just arrange three arguments spatially around a symbol. The space subdivides recursively, so elements end up being positionally determined, somewhat like what S-exps do in 1D.

I can format equations in latex in fewer characters than I could express in Lisp, so what you’re saying about 2D vs 1D really doesn’t make any sense.

LaTeX is (understandably) geared toward single-character variable names, and provides canned control sequences for common functions like \sin \cos. Try it with variable names that are two or more characters, and user-defined functions.

The fact that lisp syntax introduces no extra characters and no extra noise is my point; I'm glad we agree.

The slide that the Racket folks presented recently on allowing non-parenthesized syntax literally had “I <3 ( )” branded to the top. I think you’re mischaracterizing the position of Racket developers, who are interested in catering to folks who don’t want to spend a good 20 minutes on how to use ParEdit.

I like the parens for the structured editing they allow. Also, you don't need parens to be homoiconic.

Reply on news.ycombinator.com