William Bland has blogged about the Common Lisp packages COVER and ITERATE. I don't use ITERATE, but my group at work uses a modified version of COVER to ensure adequate unit testing of an important program. I was using it just this week and found several new bugs.

COVER is nearly 15 years old and is showing its age. It doesn't handle coverage of iteration constructs very well. It's ignorant of methods and generic functions. The way it's implemented involves destructive modification of lisp objects that occur as literal constants in compiled code (which is unconforming under the ANSI CL specification). Its internal logic is difficult to understand, if clever. It doesn't allow one to count uncovered branch points, just the number of uncovered code subtrees. It doesn't allow one to dump and reload coverage information, or combine coverage information from separate runs.

I've been thinking about reimplementing COVER to deal with these problems. Also, I would like the action taken on visiting an uncovered code segment to be dynamically reconfigurable, probably via CL's OO mechanisms. I want to do automated glassbox testing; COVER could provide feedback to a test generator, steering it (via genetic algorithms?) to visit code segments that have not been extensively tested. I'd want it to be able to maintain information beyond just 'some execution since the last global reset has visited this branch'.

I've spent the last 12 days cataloguing gcl's failures in ansi-tests. Having gone through all 1900+ failures, I've found there appear to be about 284 distinct bugs (plus any bugs not detected by the tests or masked in the test suite by other failures.) The biggest improvements in failure numbers would come from implementing READTABLE-CASE and the proper return value for FORMATTER functions; the deepest issues probably involve the type system (GENERIC-FUNCTION should be a subtype of FUNCTION, for example, and FUNCTION should not intersect the type CONS.)

Camm has been busy this summer with improvements to GNU Common Lisp. GCL is getting more efficient; on the ACL2 benchmark it's expanding its lead over the competing lisps, with more improvements coming (granted, ACL2 may be tuned for GCL, and vice versa). CONS cells have been shrunk to two words from three, reducing memory usage by 1/3, and there's a new fixnum scheme that reduce memory accesses. There are also lots of type propagation enhancements and type-driven optimizations. There's even progress on ANSI compliance, with bug fixes coming in.

GCL has this nice feature (due to the late Prof. Schelter) where it can automatically generate type proclaims for functions from type propagation on the program as a whole. GCL generates better code with proclamations, so these can really help. If you're benchmarking an application on GCL try out this feature.

Heh.

Any paper ending in a limerick has to be good.

A former coworker of mine has a blog that often talks about programming language ideas. He points out that Dussad's call for a statically typed Lisp-like language could be met by ISI's STELLA.