[xcvb-devel] [alexandria-devel] XCVB patch for Alexandria

[Attila Lendvai]

>> wouldn't it be nicer to do it using :compile-depends-on? if i'm not
>> way off, that is...
>>
> You can also do that.
>
> But if a function is used by macros, you'll save a lot by doing the
> right thing, i.e. putting that function in an EVAL-WHEN.

[i'm moving this discussion from alexandria-devel to xcvb-devel]

...if used by macros _in the same file_ (well, at least for 99% of
current CL programmers)

i'm slowly getting used to the idea of accepting these scattered
eval-when's, but i'm sure you'll get into many questions from
maintainers who will be reluctant to scatter the code with
eval-when's.

also, reading your readme and blog post on how eval-when needs to be
used, i'd consider exporting an eval-always from xcvb.

finally, some suggestions for the relevant part of the readme that can
be copy-pasted for reluctant maintainers:


"To conform with the CLHS (see section 3.2.2.3), any defun, defvar or
other side-effect must be effected in the compilation environment to
be available for use in macros, while compiling either the current
file or any further file. This means that these effects should be
enclosed in an (eval-when (:compile-toplevel :load-toplevel :execute)
...). (See on my blog a discussion of eval-when.)"

i'm missing a short elaboration on why it's so different to asdf.
namely that asdf first compiles a dependency and then always loads it
_before_ it goes on compiling anything else that depends on this file,
so with asdf the eval-when is only needed when used by a macro in the
same file. asdf always follows a compile-then-load pattern when going
through dependencies, while xcvb can go on a different path.


"Respecting that constraint will make your programs better conformant
with the standard, but will also allow for faster recompilation (where
CFASLs are available), since CFASLs may be smaller and faster to load
than FASLs, and subject to less variation which may trigger fewer
recompilations."

i would bring this paragraph above the detailed discussion on the
various type of dependencies and put more pressure on why it's good
for the user. the argument that that it's "more conformant" is
questionable, so i would turn it into a sidenote. because the standard
doesn't say a word about how you split up your program to files and
what is a build tool, and what it does with them, and in which order
they are processed, and how with-compilation-unit is used, etc...

hth, and thanks for xcvb, looks more and more intersting!

-- 
 attila