Comment by TeMPOraL | Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

I see a fifth column growing here.

The core problem (sort of created here) is about how lispy Clojure should be. Unlike most programming languages, Lisp code isn't meant to be fully statically analyzable. This affect indentation as well, because the "full picture" of syntax is only available at runtime.

Consider a macro invocation:

  (foo bar
       (some args)
       (some other code))

vs.:

  (foo bar (some args)
    (some other code))

Which indentation style is the correct one? That depends on what "foo" is. If it's a function, then the first one. If it's just a regular macro, it's still the first one. But for some particular macros - like defun in elisp/CL, the valid syle is the second one. You can't, in general[0], know that until runtime. That's why the Lisps usually give you tools for that. In Common Lisp, you have &body, which works like &rest but also hints that the expected indentation is like the 2nd case I shown here. In Clojure, you have metadata - you can attach e.g. {:style/indent 2} to your macro, which signals that desired indentation changes to 2nd form on third argument.

My personal opinion - most Lisps are designed for interactive, in-image work. So is Clojure. If you want to have a completely static formatter, go back to coding Ruby or Python.

--

[0] - You can guess it in simple cases, but not when you're dealing with macro-writing macros, i.e. code that writes code that writes code.

> Which indentation style is the correct one?

There is no correct one. There are aesthetic preferences to make Lisp code readable. Lisp has code formatters for decades and Common Lisp comes with one in the standard (the pretty printer). Tools to format (not just indent) textual Lisp code has also been available for decades, but are less used.

> If you want to have a completely static formatter

The proposal here is to ignore the programming language Clojure and format all code only on the expression level.

Isn't LISP a language that prides itself in having no special forms? A macro is a macro is a macro.

    (macroname
       first-param
       third-param
       fourth-param
       ad-infinitum)

This is the only case (there are no special, or complex, or any other cases).

Besides, if you took your time and actually read the article, you'd see `defn` in the examples.

> Isn't LISP a language that prides itself in having no special forms

No, that's a misconception. Lisp has special forms from day one (1960). On day two (1962), macros were added -> they implement even more syntax.

> A macro is a macro is a macro.

At the syntax level, yes. But indentation is not a syntax-level concern, but a semantic one. Speaking Clojure,

  (defn function [arg]
    {:some-op arg})

has the exact same syntactic structure to

  (assoc-in some-map
            [path]
            {:some-key path})

but it's expected to be indented differently because of the difference in meaning between defn and assoc-in.

Lisp allows you to use macros to provide new symbols that, put first in a list, imply something else than function call. So user-defined forms are put on equal footing with things like if or defn. And user-defined things can generate more user-defined things that are meant to be indented like defn. Hence the need for loading the code for correct indentation.

Nah. I still don't see the difference :) To me all of these are some macros/functions that expect certain parameters. Makes it much easier to reason about code IMO (especially if they are indented similarly).

Even the basic lisp mode in Vim recognizes the difference. There is a :set lispwords=... list of symbols that are operators. They get indented like this:

  (lispword a b c
    d e f
    g h)

whereas symbols not in the set like this:

  (not-lispword a b c 
                d e f)

This is important so we don't end up with this:

  (let ((x y))
       form
       form)

or, vice versa, this:

   (list (item 1) (item 2)
     (item 3) (item 4))

Is there no way out, to run the formatter after the macros?

You've already made the crucial step then - you've loaded the code. The author apparently wants to avoid that.

You could get away with parsing the code statically in the most trivial cases, but to do it even remotely correctly, you'd have to parse all the code, and only then format individual files. A lot of work for no good reason, and it wouldn't save you from macro-writing macros.

In a large Lisp project, this would screw a lot of things up. I don't have relevant Clojure example here, but in Common Lisp, I worked on a pretty big codebase (CLIM2), where trying to indent things without loading the code into a Lisp image would screw up indentation in 50+% of the files - because a lot of frequently-used macros were written by other macros.

Reply on news.ycombinator.com