[Haskell-cafe] Cyclic Inclusions

[Thomas Davie]

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  
>> 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