(I still haven't found a way to describe it to non-programmers.)
Wart is an experimental, dynamic, batshit-liberal language designed to eventually be used by small teams of hobbyists writing potentially long-lived software. The primary goal is to be easy for anyone to understand and modify. This goal goes for both code written in Wart, and the code implementing Wart.
$ git clone http://github.com/akkartik/wart $ git checkout c73dcd8d6 # state when I wrote this article $ cd wart $ ./wart # you'll need gcc and unix ready! type in an expression, then hit enter twice. ctrl-d exits. 1+1 ⇒ 2
Small core
The best way to be accessible is to minimize code. Wart is based on Lisp because it seems the most powerful and extensible core for the lowest implementation cost. But that's just the core; read on.
(+ 1 1) ⇒ 2 '(1 2 3) # lists look like function calls ⇒ (1 2 3) # quoting prevents treating them like calls (def (foo x) # define functions using ‘def’ (+ 1 x)) (foo 3) # call functions using parens ⇒ 4
Clean syntax
The crown jewels of Lisp are its macros, a massive tool for maximizing density in a readable way. Wart tries to question all of Lisp's design without compromising the power of macros. It can guess parens from indentation to be more accessible to non-lispers.
if (odd? n)
prn "odd" # prn = print to screen
Used tastefully, taking out parens can make code markedly more readable. My heuristic is to skip parens when I want to highlight side-effects and control-flow, and to insert them when I want to indicate functional computation.
In order to provide macros, Lisp uniformly uses prefix everywhere, including for arithmetic. Wart provides infix operators in an elegant way without compromising macros.
4 * 3 # same as (* 4 3)
⇒ 12
This has historically been hard to do because of the burden of providing precedence rules for nested expressions that are both intuitive and extensible. Wart's infix operators have only one hard-coded precedence rule: operators without whitespace are evaluated before operators with whitespace.
n * n-1 # does what you expect
(The catch: you can't use infix characters like dashes in variable names, something lispers are used to.)
Infix is most useful in arithmetic-heavy code for graphics and so on. But it has uses beyond arithmetic. For example, sometimes the clearest way to describe a sub-computation is as a pipeline of operations:
(c -> downcase -> rot13 -> upcase)
There's a final convenience beyond indentation-sensitivity and infix: all function arguments can be referred to by name. Individual calls can decide to pass all their arguments in order, or to insert names to reorder or emphasize specific args.
4-3 ⇒ 1 def (subtract a|from b) # 'from' is an alias for the first arg a-b subtract 4 3 ⇒ 1 subtract 3 :from 4 # refer to 'a' with its alias ⇒ 1
Argument aliases can also be used for pattern matching, like Haskell's as-patterns:
def (foo (a | (b c))) # 'b' and 'c' name parts of list 'a'
(list a b c)
(foo '(1 2))
⇒ ((1 2) 1 2)
Names
After succinctness, the biggest lever for laying out the big picture is a coherent system of names. It's not enough for names to be well-chosen in isolation, they also need to work well together. Wart tries to do this. In addition, it tries to maintain the hard-won coherence over time by allowing all names to be extended and overloaded in arbitrary ways. So you never have to define words like 'my_malloc' or 'append2' or 'queue_length'. Just override the existing name or tweak it for your special corner case.
def (len x) :case (isa queue x) ..
Such extensions to len can be made at any time, and might be arbitrarily far from each other. This makes it easier for all queue-related code to stay together, and so on.
Wart's primitives themselves pervasively use this technique. We first build def to define simple functions, and later add support for :case. The if primitive at first chooses between just two branches, and is later extended to multiple branches.
Organization
You should be able to do just about everything you want in Wart. However, Wart's internals are also intended to be extremely readable and hackable if you ever need to get into them. Its directory organization is designed to provide a high-level tour of the codebase. Just start reading at the first file and skim the first few files to orient yourself. You don't have to read each file to the end; important stuff is at the top and internal details further down. Start a new file with a numeric prefix, and it'll be loaded when Wart starts up. Reimplement a primitive from xxx.wart to xxx.cc for speed, and the new version will be picked up when you restart.
Tests
Wart is thoroughly unit tested.
$ ./wart test
The tests can be a valuable tool to interactively improve your understanding. Make a tweak, see if existing tests continue to pass. See a line you don't understand, or something that seems redundant? Change it, see if the tests pass.
Speed
Wart is currently orders of magnitude slower than anything you're used to. I've had some limited success using it for prototyping and then gradually rewriting key pieces in C. But even this currently only takes you so far. I'm playing with experimental primitives in the core interpreter that will make partial evaluation as easy as passing code through eval multiple times. But they're still in development.
Where I came from, where I'm going
Wart started with an observation: good programmers build clean and elegant programs, but programs grow less elegant over time. We start out clean, but invariably end up making a mess of things. Requirements shift over time, but reorganization is not convenient enough to keep organization in sync. Historical accidents don't get cleaned up. Newcomers don't have the comprehensive big-picture view of the original authors, and their changes gradually dilute the original design. As coherence decays, so does sense of ownership. The big picture becomes a neglected commons, too hard to defend and nobody's direct responsibility.
How to fight this tendency? Perhaps we can better preserve sense of ownership by minimizing constraints.
-
Make creating new files easy, so there are no constraints in how a
file can be organized. This will hopefully improve the odds that file
organization will continue to reflect reality as requirements shift and the
architecture evolves.
-
Keep features self-contained in files, so a feature can be dropped simply by
deleting its files, and the rest of the project will continue to build and
pass its tests. (There's a new
version
of this project where I try to take this idea to the limit.)
- Backwards compatibility is a huge source of constraints that can bleed ownership. What would a language ecosystem be like without any backwards-compatibility guarantees, super easy to change and fork promiscuously? Wart has no version numbers, and new versions and forks are free to change all semantics to their hearts' desire. Instead of a spec or frozen interfaces, we rely on automated tests. Wart programs are expected to be as thoroughly tested as Wart itself, and to buy in to the investment of hacking when upgrading. The hope is that upgrade effort might be higher than the best-case scenario in other languages, but the worst-case time will remain tightly bounded because clients of libraries will be more likely to understand how they're implemented, and so be more empowered.
The hypotheses are a) that making the global organization easy for outsiders to understand will help preserve the big picture, b) that making reorganizations more convenient by eliminating constraints will help keep the big picture in sync with reality, and c) that understandability and rewrite-friendliness are related in a virtuous cycle. Understandable codebases help outsiders contribute better organizations, and rewrite-friendly codebases help newcomers hone their understanding by attempting lots of reorganizations in sandboxes.
These hypotheses are all hard to verify, I don't expected the job to be done anytime soon. I'd love feedback from people unafraid to bounce between language and implementation. If that's you, check it out and tell me what you think. There are many more Wart code samples at Rosetta Code.
Credits
As an experiment in designing software, Wart was inspired by the work of Christopher Alexander, David Parnas, and Peter Naur. As a language, it was inspired by Arc. Discussions on the arc forum helped develop many of its features.
comments
Comments gratefully appreciated. Please send them to me by any method of your choice and I'll include them here.
(def (sqr x) (* x x)) => (object function {sig, body, }) (sqr 12312312312312321) => -180362177734089727 (sqr 10000000000000000000) ./014build.cc:31 dropping precision for bignum 10000000000000000000 => 1e+38This is what I would expect: