: Michael Weber <michaelw+alexandria@foldr.org> Don't add any of these kludges, and instead reorganize code such that EVAL-WHEN is not sprinkled throughout the code.
: Attila Lendvai <attila.lendvai@gmail.com> IOW, you propose that the current way of categorizing definitions into separate files should be changed so that it is based on evaluation stages.
this is certainly a cleaner solution in some ways, but it also means that for example if an ensure-car is used in a macro in the same module, then it must be moved from lists.lisp to compile-time-stage.lisp.
i would even be ok with that, but it's not any less kludgy from another point of view.
It would be extraordinarily kludgy, especially for functions that are just MEANT to be used by macros. Why require them to be in a different file from the macros that use them, or cause the file in which they are to be loaded in a special way? That a macro uses a defun instead of an flet should be an implementation issue not exposed to the users of the macro, who shouldn't have to know that "hey, for this file, we should use the FASL, not the CFASL", just because of how the author (failed to) organize the internals of his files. Even assuming only FASLs and not CFASLs, the constraint of segregating functions by stages is extremely cumbersome -- all the more when a function suddenly gets "promoted". Instead of being wrapped in an EVAL-WHEN, it has to be shipped to another file that maybe has to be created just for this purpose? Ouch. The standard just doesn't guarantee that a function not in (the equivalent of) EVAL-ALWAYS will be available for use by macros, whether while compiling the same file or at any time in the future. Get over it, and please stop relying on assumptions that might be valid with how ASDF currently works, but that should really not be taken for granted -- and I can definitely envision a case where ASDF's COMPILE-OP and/or POIU's PARALLEL-COMPILE-OP would in the future use CFASLs where available. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Perhaps those of us who care about quality programs have not spoken up often enough -- `for bad programs to triumph requires only that good programmers remain silent.' I call this passivity the `Silence of the Lambdas.' -- hbaker