The Parenthesis Problem

keyboard image

Lisp, referring to the category of programming languages, uses lists to do computer programming. In order for this to be useful, many lists are needed. And not just a succession of lists; items in a list can be another list, and that list could contain another list.

Programming in Lisp, short for List Processing, means having many lists appear on the programmer’s screen. To know where lists begin and end, the notation for these lists involves parentheses. The result: parentheses absolutely everywhere. This is problematic, because after a certain point it can become difficult to understand what’s going on.

Few programming languages in common use work like this. Commonly used programming languages, like Python, JavaScript, C, don’t use this kind of syntax. And so, they don’t have this kind of problem.

With this problem being unique to Lisp, why bother with Lisp? The answer is that having a programming language syntax work this way brings all sorts of unique advantages with it. Indeed, much has been written about this. 1 2 3 4
This is why Lisp continues to see some use today in various forms, despite the parenthesis problem.

Attempts have been made to solve this problem by changing the syntax. But the syntax isn’t the problem. The problem concerns itself with having a certain kind of information (code), and the need to communicate the meaning of this information to the user. Rather than inundate the user with parentheses, something else should be shown. Something that’s easier to understand. The question is: what is that thing? What is the alternative view to this type of computer code?

Problem-solving

Computer programming is done on a computer, and editing programs are used for that purpose. These programs display the code that is being worked on.

Rather than change the code, the idea is to change how the code is displayed in the editor…

Let’s make an attempt to solve this problem by experimenting on a sample of code.

(define (factorial n)
  (if (zero? n)
      1
      (* n (factorial (sub1 n)))))

If the parentheses present such difficulty, why not just… not visualize them?

 define factorial n 
   if zero? n 
      1
      * n factorial sub1 n

Well. That was easy.

But wait. What if I forget to type the parentheses? What if I type a closing instead of opening parenthesis? That sort of thing would entirely change the meaning of the code, and I wouldn’t be able to tell the difference.

Let’s continue on a screenshot of code so we can tweak the image any way we want. Rather than replace parentheses with blank characters, how about we just reduce or minimize the shapes, by replacing them with, say, dots?

code image

That’s better, but… that still doesn’t solve the problem of not knowing when something starts or ends. We’re going to need symbols that are distinct.

So instead of dots, how about half circle shapes.

code image with half circles

Now we’re getting somewhere.

This is an alternative, but we need to remember we’re not just looking for an alternative. We’re looking for something that’s strictly better than what we had before. Is this really better? Now that I look at this example a bit more, I’m noticing it’s a bit difficult to read. I can’t tell whether that half circle shape is opening or closing without examining it carefully. Maybe the shapes are just a bit too small.

So first we got rid of parentheses entirely, and while that seemed nice at first, all that did was turn the ’too much information’ problem into a ’not enough information’ problem. Changing them into dots nearly worked, but it became clear we needed something that would also tell us where something starts and ends. Taking that into account, the dots needed to be distinct, so we ended up with half circle shapes. While what we have now is promising, it’s not quite satisfactory because those half circle shapes are just a bit too small. It would seem the last step is to simply make them larger.

How about making them about the same size as the other characters?

If that’s the last problem we need to solve, the final result could be the alternative view to the code we’ve been looking fo–

image with big half circles

Fail

Wow. Okay, that did not work at all. All we ended up doing was recreate parentheses. An ugly, clumsy version of parentheses at that.

I don’t get it. I appreciate useful things. If visualizing parentheses is useful, why does the sight of them vex me so? Where is this feeling of dissatisfaction coming from?

Maybe that failed attempt just wasn’t radical enough. Rather than try to replace the parentheses with different characters, perhaps the answer is to render something completely different. By drawing circles on the screen to represent lists, for example. Sure, you’d end up with lots of circles on the screen, and it would probably be way worse than parentheses, but it’s evidence an alternative view is possible. What other alternative views are there? Which can produce the desired result?

This reasoning may seem odd, but I happen to believe that the feeling of dissatisfaction is in fact evidence that the solution already exists. It just needs to be found.

Several Attempts Later…

Submitted for your approval: My Answer to The Parenthesis Problem


  1. Why Lisp? http://blog.rongarret.info/2015/05/why-lisp.html ↩︎

  2. How Lisp Became God’s Own Programming Language
    https://twobithistory.org/2018/10/14/lisp.html ↩︎

  3. An Intuition for Lisp Syntax https://stopa.io/post/265 ↩︎

  4. I have my own idea of what I think the biggest advantage of Lisp is, which I may write about in the future. ↩︎