Beyond correctness and conformance: applicability and performance

Last time was about how the team is working to advance ABCL's correctness and conformance; these two are mostly measured by the ANSI tests. Next to those characteristics, we also introduced a measure called 'applicability'. It's a qualitative measure which we say increases when (more) existing Lisp code is made to (or is proven to) work with ABCL.

So far, we've been using the following software to test (and improve) the applicability of ABCL:

• Maxima
• AP5
• cl-bench
• SLIME/swank

Next to the above we know a number of people are using ABCL to write their own applications. See the testimonials page. If you have software to complete the list of known-working software, please contact our developers list. If you have software which is almost working, please help us improve our applicability by at least reporting; patches to resolve the situation are even more appreciated.

Another aspect of our user experience is performance. Being an implementation on the JVM, of course we're restricted in many ways on which code we can generate and how we store our data. As a result we'll be in a disadvantageous position to start with.

That doesn't mean there's no room for improvement in ABCL at the moment. The development team has gradually moved into the area of profiling and improving the implementation over the last 2 or 3 months. As it turns out, there's still a lot which could be improved, with the following examples:

• Support for unboxed single-floats and double-floats in the compiler
• Careful creation of new objects - focussing on re-use - in the support library
• Prevent unnecessary re-opening of system files (fasls and others)
• Prevent unnecessary loading of compiled files (which clear out the HotSpot caches)
  

As you can see, more parts and more aspects of the system are receiving our attention.

ABCL actively developed

Last year around August, Peter Graves asked me (Erik Huelsmann) to take over ABCL (Armedbear Common Lisp) development. I gladly accepted.

Since then we - a small team of lisp hackers - have been hard working to improve ABCL. Yesterday it was pointed out to me that the Lisp community was probably unaware of the renewed energy being put into ABCL's development.

Our efforts have concentrated on 3 areas of improvement:

• Correctness - doing right what is already implemented
  
• Conformance - implementing what the spec says should be
  
• Features - things the spec doesn't require, but which are too handy not to provide standard

With respect to correctness and conformance we are glad to be able to say that the ANSI test failures have been drastically reduced to below 40 (coming from hundreds).

With respect to the features, we're proud of our achievements, which are two-fold: first of all we have added some Lisp features most implementations provide (

• compiler improvements such as unboxed local variables
• MACROEXPAND-ALL
• COMPILER-LET and
• locking primitives for threading
• lots of other stuff;

second we added some features which matter for a Lisp in a Java environment:

• JSR-223 support: being a scripting engine for any Java application
• Threading primitives (different ones) which inter operate with the Java world
• Improved Ant-based build system
  
• more...

But we did more: ABCL was separated out of the source tree of the J editor (and moved to common-lisp.net). A wiki, mailing lists, new project pages, a repository and defect tracker have been set up. A bi-monthly release schedule has been put into place - source releases only for now and we're working toward binary releases too.

On this blog, I will discuss the advances and difficulties that make up the ABCL development experience.