On 13 Aug 2008, at 05:06, [EMAIL PROTECTED] wrote:
G'day all.
Quoting Thomas Davie <[EMAIL PROTECTED]>:
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
odd
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
other,
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!
Bob
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
