[alexandria-devel] eval-always, defun-always, etc...

[Faré]

>>: Michael Weber <michaelw+alexandria at 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 at 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