Hi David,
David Kastrup <d...@gnu.org> skribis:
> l...@gnu.org (Ludovic Courtès) writes:
[...]
>> The order in which files get compiled does not matter; the semantics of
>> programs do not depend on whether code is being bytecode-interpreted or
>> just interpreted by (ice-9 eval).
>
> Little things like
>
> (define-public fancy-format
> format)
>
> (define-public (ergonomic-simple-format dest . rest)
> "Like ice-9's @code{format}, but without the memory consumption."
> (if (string? dest)
> (apply simple-format (cons #f (cons dest rest)))
> (apply simple-format (cons dest rest))))
>
> (define format
> ergonomic-simple-format)
>
> tend to make quite a difference depending on whether they are loaded or
> not before compiling.
>
> That one actually caused a lot of wasted effort on
> <URL:http://code.google.com/p/lilypond/issues/detail?id=1780>
The ticket is a bit too dense for me. What’s the operational difference
between compiling and evaluating the above code?
>> The only reason you might want to compile files in topological order
>> is performance.
>
> And macros. And redefinitions. And module hierarchy.
I think you’re talking about what should be *re*compiled when a module
has changed, right?
What I was mentioning above holds for one-shot compilation of a set of
modules, but you’re right that things are trickier when it comes to
incrementally changing part of that module set.
Thanks,
Ludo’.
