Goals

The overal goal of the "Readable Lisp s-expressions" project is to develop, implement, and gain widespread adoption of more readable format(s) for the S-expressions of Lisp-based languages (such as Common Lisp, Scheme, Emacs Lisp, Clojure, and Arc).

Specific Goals

Here are our more specific goals for a programming notation for Lisp-like systems, and how well we believe we've met them in our [Solution]. We wanted notation(s) that were:

• Primary Goals
  • Readable. Any notation should be more “readable” to the uninitiated, in particular, it should look like more traditional notation. For example, ideal format would support infix notation for operations that normally use infix (+, -, <=, etc.), support having function names before parentheses, and not require as many parentheses. Today's developers have to collaborate with many others, and having an easy-to-read notation is important for enabling collaboration. Goal met - we believe sample code looks far clearer.
  • Homoiconic (mappable). There needs to be an obvious and clear (to humans) mapping to and from current s-expression notation, which must work for both data and code. The key advantage of Lisp-like languages is that you can easily manipulate programs as data and vice-versa; that must remain for any modified syntax. Otherwise, there’s no point; there are lots of other very good programming languages that support infix and other nice notations. This means that the notation must be homoiconic. Goal met.
  • General. It must not be tied to one particular underlying semantic. If you have to edit the parser after you write a macro, something is wrong. Goal met.
  • Standardizable. It should be very standardizable across all systems that accept s-expressions (Lisp's original syntax); nobody wants to relearn basic syntax everywhere. It should be useful in Common Lisp, Scheme, Emacs Lisp, Arc, ACL2, DSSSL, AutoLISP (built into AutoCAD), ISLISP (standardized by ISO) BRL, and so on. A thread about guile noted this very need. Goal met.
  • Work with macros. There will probably be some tweaks for indenting and infix notation (especially since infix reorders things!), but macro processing should continue to work in most cases. Goal met.
• Secondary Goals
  • Easily implemented (relatively speaking). It must not require tens of thousands of lines of code to do. However, if it takes a little extra code to produce nice results, that is fine; better to do things well once. It need not be easily implementable via a few tweaks of an existing reader, though that’d be nice. Yes, rewriting a reader is a pain, but those only have to be written once per implementation. Note that even among implementations of a particular language there is often much variance, so the format needs to be simple enough to support many implementations. Goal met.
  • Quote well. In particular, for both forward quote (’) and backquote/quasiquote (‘), it must be easy to find the end of the quote, and for backquote/quasiquote, it would be very desirable to support initial comma (,) and friends to locally reverse the quoting (the whole point of quasiquoting). Goal met.
  • Backward-compatible. Ideally, it should be able to read regular s-expressions (at least normally-seen formats of them) as well as the extensions. I’m willing to give a little on this one where necessary. Goal generally met. There are bizarre edge cases, such as someone writing a(b) and expecting that to be two separate values, but normally-formatted s-expressions work just fine, and pretty-printers can automatically fix the rest.

Our notion is that the underlying system would not fundamentally change... instead, systems would simply update their reader, so that it can an extended notation and convert it into s-expressions. A printer could then redisplay s-expressions later in the traditional notation, or same kind of notation used to input it. It would also be nice if the notation was not confusing or led to likely errors.

For any syntax to be widely used, there must be trustworthy, widely-usable implementations. Thus, adoption would be helped by having at least one FLOSS reference implementation with a generous license that permits use by proprietary programs and Free-libre / open source software (FLOSS) programs. Any FLOSS software should be GPL-compatible, since there is so much GPL’ed code. This reference implementations would need to be widely portable and modular, so that it can be widely used as a starting point. Thus, we've worked to develop software under the MIT license; it meets those requirements, and it is the license the Scheme SRFI ("surfie") submissions use.

We have implemented this approach for both Scheme and Common Lisp, since those are both widely-used Lisp-based systems.

You might be interested in reviewing our [Solution], or in seeing our [Rationale].