[Haskell-cafe] Cyclic Inclusions
tom.davie at gmail.com
Wed Aug 13 04:26:57 EDT 2008
On 13 Aug 2008, at 05:06, ajb at spamcop.net wrote:
> G'day all.
> Quoting Thomas Davie <tom.davie at gmail.com>:
>> Why is separate compilation important?
> I'm a little shocked that anyone on this list should have to ask this
> question. Two people have asked it now.
> The simplest answer is that unless your program fits in cache, it
> takes longer to compile two modules concurrently than it takes to
> compile them separately. This is even more true if one of those
> modules does not actually need recompilation.
> The longer answer is that in the Real World, programmer time is
> far, far more precious than computer time. Every second that the
> programmer waits for the computer to finish some task, there is a
> priority inversion.
Really? So you're using YHC then? It after all compiles *much*
faster than GHC, but produces slower binaries. To be honest, ghc
compiles things so fast (at least on any of my systems) that I
couldn't care less if it took 10 times as long (I would however like
some added convenience for that time spent)
> It's therefore highly desirable that jobs done by computer are as
> fast as possible or, failing that, as predictable as possible, so
> the programmer knows to do something else while waiting.
> Separate compilation puts a predictable upper bound on the amount
> of recompilation that has to be done given some set of changes.
> True, so does requiring recompilation of a package as a whole, but
> Haskell development would then be notorious for its sluggishness.
It does? If I compile a module on which lots of other modules depend,
I have to do lots of recompilation... If I compile a module which is
in a cyclic dependancy group, I have to do lots of recompilation, I
don't see that there's a difference here.
>> I can understand your point
>> about a module on it's own not being analyzable, and that that's an
>> property -- on the other hand, the rapidly emerging "atomic" unit in
>> Haskell is the package, so I see no reason why modules within one
>> package shouldn't depend on each other.
> Implicit in my working definition of "module" is that a module has a
> well-defined interface. Am I the only one who has that understanding?
> (Well, me and David Parnas, at any rate.)
> For the record, I have no problem with modules depending on each
> so long as they only depend on their well-defined interfaces.
That's a fair point about programming style, otoh, I don't think it's
a reason to restrict users to not using cyclic dependancies.
>> Finally, as chris suggests, if separate compilation is important to
>> you, why not have a flag in ghc -frequire-hi-boot or something?
> Well, if I wanted separate header files, and the inevitable multiple-
> maintenance headaches associated with them, I'd program in C. Except
> for mutually recursive modules, GHC can and does generate header files
> automatically, so I don't see why my time should be wasted doing the
> job of a compiler.
> If something is preventing the compiler from doing that job, then that
> something should be fixed.
Something *does* prevent the compiler doing that job -- the fact that
ghc can't deal with cyclic module includes without an hi-boot file.
This is *exactly* my point -- I don't see why my time should be wasted
doing the job of the compiler just because I happen to have a cyclic
dependancy, that the compiler could quite happily sort out, by making
my compile time in this situation slightly longer.
If I *really* think I'm going to save more time by writing a hi-boot
file, then I would be able to turn on the option!
More information about the Haskell-Cafe