Hubris

Hubris

Our [Solution] hubristically claims to be superior to classic Lisp syntax. The Lisp community, in general, tends to reflexively reject attempts at improving Lisp syntax. After all, Lisp's extremely lightweight syntax allows proper syntactic macros and simplifies defining DSL's. It is those two killer features that most deeply depend on classic Lisp syntax.

Attempts at better Lisp syntax generally wind down to every user, in the long run, increasingly using some kind of "special escape" in that syntax to write Lisp s-expressions. Dylan did. M-expressions never even got off the drawing board. Even Alan Manuel K. Gloria (one of the more prolific members of this project) first got introduced to Lisp via Cadence Skill - which has a vaguely C-like syntax complete with infix - and then eventually moved to using pure s-expressions instead of the C-like extensions of Cadence Skill.

Lisp's traditional syntax, s-expressions, is very good at making Lisp-like languages work well. The claim that, as one develops greater skill in Lisp-like languages, one gains appreciation of how s-expressions make Lisp work, is quite true.

But here in the Readable Lisp project, we think that we can do better than s-expressions.

Who dares challenge the status quo?

As our [Problem] page points out, we (David A. Wheeler and Alan Manuel K. Gloria) are not newbies to Lisp who are trying to impose other language's ideas (most notably Python) on Lisp. We have been writing code for Lisp-like languages for a long time. We know, and use, macros. We know, and use, DSL's. Alan Manuel K. Gloria has been writing code for Lisp-like languages for almost a decade now (January 2013) - hardly a newbie. David A. Wheeler has been writing for longer (30 years).

We recognize that Lisp's s-expressions have two important properties, which we expand on in [Rationale]:

1. General - Lisp's s-expression syntax has been used for various kinds of code and data: from Standard delay format used in digital IC logic design, to ordinary Lisp-likes such as Scheme, Elisp, and Common Lisp, to theorem provers such as ACL2

2. Homoiconic - Lisp's s-expression syntax is easy for human beings to parse into their component cons cells.

The "readable" project aims to keep these two properties in its [Goals], and to also have the additional goal of being "readable". It is also backwards-compatible with well-formatted s-expressions; at any time you can use traditional s-expressions, or read existing s-expressions.

What has your hubris yielded?

The "readable" project has successfully finalized SRFI-105, which specifies our curly-infix-expression syntax as an extension for Scheme. SRFI-110 is a draft SRFI defining sweet-expressions. Although SRFI's are Scheme-specific, these syntaxes are not specific to Scheme and can be used in any system that uses some variant of s-expressions. We also implemented a rigorous BNF grammar using ANTLR, which performed a variety of checked.

We have implemented the notations in both Scheme and Common Lisp (we well as in ANTLR).

We know that our [Solution] works because of our [Analysis], where we:

1. take code, written in s-expressions, for many, many, many varied languages -
2. rewrite it in our sweet-expression syntax -
3. and compare the original s-expression with our sweet-expression syntax

In nearly all cases, the removal of parentheses due to use of indentation greatly reduced the "noise" of the actual code, improving readability. Also, the switch to infix greatly assists many arithmetic-heavy code samples. In short, this notation has been tried in a variety of settings, and we've updated the notation so that it works well in many different circumstances.

Our goal is to create an updated notation that is a joy to read and write; we hope you will come to the same conclusion.