S-expressions readability

lispreadability

In a nutshell and for those who didn't know it, Lisp functions/operators/constructs are all uniformly called like this:

(function arg0 arg1 ... argN)

So what in a C-like language you would express as

if (a > b && foo(param))

is transformed to a Lisp sexp like

(if (and (> a b) (foo param)))

. As things get more real/complicated, so do their corresponding s-expressions, for me.

I'm aware that this is most likely a subjective question, but – is for many Lisp hackers this one little annoyance one will have to always deal with?

Or does one mostly get used to this (lack of) syntax sooner or later?

In any case, is adding breaklines (that you wouldn't add in your C equivalent, most times) for readability a good idea, especially on the long run? Any other suggestions would be welcome.

Best Answer

How do you parse

if (a > b && foo(param)) {
  doSomething();
} else {
  doSomethingElse();
}

The parse tree probably looks something like

if:
  condition:
    and:
      lt:
        left: a
        right: b
      function:
        name: foo
        param: param
  true-block:
    function:
      name: doSomething
  false-block:
    function:
      name: doSomethingElse

hmm... let's serialize this tree into a list, prefix notation

if(and(<(a, b), function(foo, param)), function(doSomething), function(doSomethingElse))

This parse tree format is pretty easy to manipulate, but I have one problem. I hate separators. I like terminators. At the same time, I like sprinkling in whitespace.

if( and (<(a b) function(foo param)) function (doSomething) function ( doSomethingElse))

hmm... the additional whitespace makes certain things harder to parse... Maybe I could just make a rule that the tree is represented as (root leaf leaf leaf).

(if (and (< a b) (function foo param)) (function doSomething) (function doSomethineElse)

Now my serialization of a parse tree is lisp (rename function to apply, and this probably runs). If I want programs that write programs, it's kind of nice to just manipulate parse trees.

This isn't entirely how s-expressions came about, but it was identified early, and it is one feature that lisp programmers use. Our programs are pre-parsed in some sense, and writing programs to manipulate programs is fairly easy because of the format. That's why the lack of syntax is sometimes considered a strength.

But as David said, use an s-expression aware editor. You are more likely to lose track of a closing brace in an s-expression than a closing brace in xml (</foo> only closes <foo>, but right paren closes ANY s-expression). In racket, the use of square brackets for some expressions, coupled with good indenting style, fixes most problems.

The lisp version:

(if (and (< a b) (foo param))
  (doSomething)
  (doSomethingElse))

Not too bad.

Related Solutions

Code Quality – Does Simplicity Always Improve Readability?

"Simple" is an overused word. "Readable" can profitably be defined as "simple to understand", in which case increasing (this measure of) simplicity by definition increases readability, but I don't think this is what you mean. I've written about this elsewhere, but generally something can be called "simpler" either by being more abstract (in which case fewer concepts can express more phenomena) or by being more concrete (in which case a concept does not require as much background knowledge to understand in the first place). I'm arguing that, depending on perspective, a more abstract concept can reasonably be called simpler than a more concrete concept, or vice versa. This, even though "abstract" and "concrete" are antonyms.

I'll use as an example some Haskell code I wrote a while ago. I asked a question on stackoverflow about using the List monad to calculate a counter in which each digit could have a different base. My eventual solution (not knowing much Haskell) looked like:

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

One of the answers reduced this to:

count = mapM (enumFromTo 0)

Which of these is "simpler" to understand (i.e. more readable) depends entirely on how comfortable the reader has become with (abstract) monadic operations (and, for that matter, point-free code). A reader who's very comfortable with these abstract concepts will prefer to read the (short) more abstract version, while one who is not comfortable with those operations will prefer to read the (long) more concrete version. There is no one answer about which version is more readable that will hold for everybody.

C# – Extracting Lambda Expressions from LINQ Queries for Readability

When you format a complex Linq query well enough (don't let it run on too many lines) it shouldn't be more difficult to read than a complex condition in a while loop or if statement.

The follow reads just fine to me:

var myList = MyThings.Where(o => o.ID == someID
                              && o.Name == someName
                              && IsAdd
                              || /* other conditions */).ToList();

So does the version using an extracted equals Func<T, bool>.

However, usually when I see a Func object like that, I make the assumption that it may not always be the same logic. I use a Func when the action being performed needs to be passed in externally, or determined by some condition. In this case, your Func is right next to the Linq expression itself, so it's easy to see that it's not the case, but it may be confusing if they were separated further.

Let's pretend this logic was being used in an if condition. If the logic is complex enough that you would consider splitting it out into its own named Boolean variable, it's probably justifiable to do something similar and make a Func. If you would write the condition directly inside the body of your if, it's probably simple enough to understand inside the body of your Where function.

Best Answer

Related Solutions

Code Quality – Does Simplicity Always Improve Readability?

C# – Extracting Lambda Expressions from LINQ Queries for Readability

Related Topic