As I said, I am laying the foundations for the new compiler and at the same time polishing what is being used right now.

One thing I have faced right now is a stupid problem with optimization settings and ECL's optimizater policies.

Those policies are defined to some extent in the manual and are implemented as a set of functions that query the compiler environment comparing SPEED, SPACE and DEBUG settings and deciding based on that. See it here by yourself
    http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=blob_plain;f=src/cmp/cmppolicy.lsp;hb=HEAD

I am not terribly happy with this, because the choices are somewhat ad-hoc, largely motivated by compatibility with SBCL and the constraints imposed by the specification.

For instance today I faced a problem with a function that was defined to have SAFETY 0, to get the most of the inline forms of CAR, CDR, slot accessors, etc, but then this causes the deactivation of the code that checks the number of arguments.

It is for this reason that I am considering to include a set of extended declarations, which would look as
   (DECLARE
     (EXT:POLICY-CHECK-ARGS)
     (EXT:POLICY-INLINE-SLOT-ACCESSORS NIL)
     ...)

The problem I am having right now is how to specify the interaction of these flags (which could also appear in proclamations, DECLAIM, etc) with the standard optimization settings. One possibility would be defining the whole set of optimizations as a bitmap, B. Each of the standard optimization settings would then do two things: first compute a combined mask of optimizations that are activated, A, and a combined mask of flags that are deactivated, D, and compute B <- (LOGANDC2 (LOGIOR B A) D)

It would then be easier to claim which optimizations get triggered by which optimization settings and which ones get deactivated.

Does it make sense to you?

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com