Compiler objects

[no-defun-allowed]

If we proceed with allowing more client specialization of code generated by one-more-re-nightmare, it would be necessary to introduce a representation for information for the compiler, and separate caches for code compiled with different specializations. Following the "backend" object Petalisp uses, we could introduce an object which stores this information, and classes which can be specialized on to introduce changes to the compiler.

It may also be useful to allow for different policies for holding onto cached code; a LRU cache may be more appropriate if many regular expressions are used, or a concurrent hash table if contention* over the cache table is somehow a problem.

The high level interface could be reused by providing a dynamic variable, say *compiler* which would default to a compiler object with the standard optimisations and hash table. The variable could be re-bound with another compiler object, and the provided functions would work with that compiler object.

*Our current cache is currently not thread-safe. Well, that was stupid not to do.

[no-defun-allowed]

Instead of one compiler object, we may have a "backend" object, which produces compiler component objects (such as prefix generation strategy, array access generation, etc) based on information about the regular expression to compile.