Lispin is yet another attempt to rid Lisp (or rather Scheme, at the time of writing) of parentheses:

;;; Try indented syntax yourself defun factorial (n) if (<= n 1) the 1 * n factorial (- n 1)

Curiously, the site links to my colorbox prototype as previous work. There is, however, a noteworthy difference in mindset between the two: I do not conflate source code and its presentation. It was not at all my intention to get rid of syntactical structure. Instead, I toyed with replacing its presentation by means of nested color boxes (think structure editor). The parentheses can be hidden (optionally, by the way), but they are still very much present in source code, because it makes the job of syntax-directed tools (parsers, editors, ...) easier!

Getting rid of the parentheses at the syntax level has been proposed a number of times. The advantages are not clear. However, the disadvantage is the increased importance of whitespace, and I think this is gravely the wrong direction. Source code editors often feel not obliged to preserve the exact whitespace characters in non-binary files, #\Tab expands to differing amount of #\Space characters, etc. Thus, program semantics may change without clear visible clue, which is as wrong as it can get.

Haskell with its off-side rule suffers from the same issues, but at least it has a type system to catch such whitespace-related errors. In Python, Common Lisp and other dynamic languages, such errors could easily go unnoticed until run-time.

For new (Emacs-using) Lispers who feel the presence of parentheses is distracting, I would recommend trying out parenface instead. It allows assigning a low-contrast color to parentheses. It might be all that is needed, so that you can proceed immediately to the state of complaining about missing Lisp libraries. Ahem...





I do not read comp.lang.lisp regularly, but there is an ongoing discussion about Lispin (via Paolo Amoroso).





This article is discussed on reddit, so let me clarify and expand on a few points: pjdelport wrote: I think the quote [ In Python, Common Lisp and other dynamic languages, wrong indentation can easily go unnoticed. ] meant Common Lisp with indentation-based syntax, instead of just parens. I meant to say with whitespace-based indentation, sorry for being unclear. Actually, I would say that Common Lisp as it is, is already indentation-based, sort of. Programmers rely on the indentation to understand code, not on counting parentheses. New lisp programmers (and even seasoned ones) fall into the trap of wrongly-indented code from time to time, when they indent code manually instead of relying on their editor (try out paredit, it can save your day). Fortunately, with parentheses and an almost universally accepted indentation scheme around, it is easy to reindent Lisp code automatically, and spot the mistake. Not so with whitespace-based indentation. Parentheses are merely a structuring tool for editors and other source-transformation tools (like macros). However, they are visible, and people keep complaining about them. Their first solution is "I will change the syntax", instead of thinking in the direction of a structure editor (see, e.g., LavaPE).

Cynos wrote: I came in precisely to comment about this. In Python, wrong indentation either doesn't compile or produces notably wrong results. Let me back up my claim with some data points. Exhibit A: pseudo whitespace-based indented code: if <condition>: <stuff> <stuff> <oops> How can a compiler know that <oops> was supposed to be guarded by the condition? I have seen python projects from students and watched them extending bodies of existing python code (web applications, if you must know). They experienced specifically the issues I mentioned. The code appeared to work at first despite wrong indentation (and thus semantics) in places. What can be done about it? Testing. Right. How can we ever be sure that we really caught all problems? Rigorous testing. Unfortunately, this is not easy (and subject for another rant, perhaps). So, again please, I am slow: why introduce more sources of errors? Sometimes, I could witness whitespace problems even when kiebitzing over students' shoulders long enough: they copy&pasted a perfectly good block of code from another source file. It looks exactly the same in the other buffer. They add and adjust a few lines in the middle, run the program and everything looks fine. At some point things start going wrong. If they are lucky, the web application throws a backtrace into the browser window. Unless bad indentation caused a logical error, in which case the application just not behaves like it should. But the code looks fine, so why does the error happen at all?!

Another three Edit-(Compile-)Restart-Test cycles, and the poor programmers start reindenting everything in the general neighborhood of their last edits, until things perhaps appear to be working again. The problem surfaces especially when different IDEs were used for editing python code, some parts were written in Eclipse with a python plugin, others with vi or PyPE or whatever else, and perhaps with different #\Tab conversion settings. (Note: If somebody now retorts with coding standards , I will counter-retort with herding cats and single point of failure !) What can we learn from this? My argument here is not that Lisp syntax is superior. It is that a programming language should enable writing program which give unambiguous visual clue for their underlying semantics, and we should separate between syntax and presentation. A parenthesis-less, indentation-based view for Lisp code is fine from this perspective, if it is unambiguous. If you don't like the parentheses, consider a structure editor instead of making the syntax whitespace-dependent.



