Hacker News Reader

Comment by seanmcdirmid | Hacker News Reader

Lisp syntax is like no syntax at all, it's all just direct parse trees. It is unviable without more secondary formatting than syntactic forms since it is really difficult for the eyes to balance parantheses on their own.

That LISP-style (non) syntax is successful just goes to show how little syntax really matters (I.e. the null case works), I guess.

View on HN

I get what you're saying, but that's a pretty extreme view. Parenthesis are obviously syntax, even if they look similar to the notation used to represent ASTs in other languages. They are minimal syntax, but they're still syntax (also, lisps have `"@' and sometimes {}[]).

Just because this is the internet, I'll also disagree with your second point. Lisp programmers use white space and macros to make programs more readable. Despite this, lisp's adoption trails many less powerful languages that offer more intuitive syntax. Since lisp's metaprogramming facilities allow it to effectively simulate pretty much every other style of programming, the only explanation that I can come up with for this situation is that intuitive syntax matters a lot (at least for language adoption).

Macros aren't so much syntax as they are semantics (inlined for performance, but we can still think of them as special procedure calls). Lisp has been relatively successful in its various forms, it should get some credit.

Macros serve lots of purposes. One is providing convenient syntax.

    (loop for i from 10 below 100 step 3
          when (evenp i)
          collect i)

Above is using the LOOP macro, which implements a lot of syntax for various ways to LOOP. The syntax description is actually quite long:

See the EBNF description of the LOOP macro in the standard:

http://www.lispworks.com/documentation/HyperSpec/Body/m_loop...

There are other syntactic forms which use more parentheses. For example the DEFCLASS macro. The basic EBNF syntax for DEFCLASS is:

    defclass class-name ({superclass-name}*) ({slot-specifier}*) [[class-option]]

    slot-specifier::= slot-name | (slot-name [[slot-option]])

    slot-name::= symbol

    slot-option::= {:reader reader-function-name}* | 
                   {:writer writer-function-name}* | 
                   {:accessor reader-function-name}* | 
                   {:allocation allocation-type} | 
                   {:initarg initarg-name}* | 
                   {:initform form} | 
                   {:type type-specifier} | 
                   {:documentation string} 

    function-name::= {symbol | (setf symbol)}

    class-option::= (:default-initargs . initarg-list) | 
                    (:documentation string) | 
                    (:metaclass class-name)

The DEFCLASS macro implementation will check some of that automatically, but much of the syntax has to be check by the macro in the implementation code.

> we can still think of them as special procedure calls

That's not a good idea. It's misleading.

> the only explanation that I can come up with for this situation is that intuitive syntax matters a lot (at least for language adoption)

Where intuitive is, as always, defined as "things I've seen before". Which makes the argument boil down to "popular things are similar to other popular things".

Currently the two most popular types of syntax are C-like (C++, Java, C#, JavaScript, etc.) and Python-like (Ruby, Elixir, etc.). Prolog suffered from the AI Winter similarly to Lisp, and thus Prolog-like languages (e.g. Erlang) still get complains about their "arcane syntax", just like Lisps.

Lisp syntax is two stage: at the first level it is a data syntax. It provides via s-expressions a textual representation for data. It also helps to format data to make it more readable to a human reader:

  CL-USER 45 > (pprint '(foo bar (alpha beta gamma) (delta alpha beta gamma)))

  (FOO
   BAR
   (ALPHA BETA GAMMA)
   (DELTA ALPHA BETA GAMMA))

but the tabular print may help with reading. S-expressions know nothing about Lisp syntax. All they do is describe how to textual represent data like lists, symbols, numbers, strings, arrays, ...

At the second stage is Lisp program syntax. It is defined on top of s-expressions.

This is the syntax for DEFUN, which defines functions:

  defun function-name lambda-list [[declaration* | documentation]] form*

A function name, the lambda-list, declacations and forms have then more syntax.

If we have a defun form, we also want it formatted.

I take the Lisp form above, and change the first identifier to defun so that it is valid Lisp code:

  CL-USER 46 > (pprint '(defun bar (alpha beta gamma) (delta alpha beta gamma)))

  (DEFUN BAR (ALPHA BETA GAMMA)
    (DELTA ALPHA BETA GAMMA))

Now you see that the printer recognizes that DEFUN is a valid Lisp macro and formats it this way:

   DEFUN function-name argument-list
    form-1
    ..
    form-n

It does format it differently from the similar structured list above. As a Lisp programmer I expect the second formatting for valid Lisp code.

The Lisp programmer uses the s-expression syntax as a clue, but actually follows the special formatting/indenting of Lisp code to read it. The experienced programmer doesn't see the parentheses, but follows the head symbols (here DEFUN), the special grouping, the blocks, the indentation. As a Lisp programmer I know that after the name the argument list follows and then optional type declarations and documentation string. After that I expect the body forms as a sequence of forms.

It's clearly not unviable, seeing as how many perfectly viable languages that use Lisp syntax.

I said it is unviable without more secondary formatting, not that it is unviable period.

Have you ever programmed in a lisp language? Balancing parentheses with your eyes is not something I've ever had to do. If you have to do that you're using the wrong editor

Yes. And we avoid balance parentheses with secondary formatting information, otherwise it becomes a mess quickly.

Reply on news.ycombinator.com