RE: ghc --make feature request

2001-10-30 Thread Simon Peyton-Jones

| Note that in GHC, the version number of a function can 
| often change for hard-to-spot reasons.  You just need to 
| change (for example) the strictness properties of the 
| function, which can be very easy to do when making changes to 
| your code.  The compiler cares about (much) more than just 
| the types of imported objects.  I tend to expect recompiles 
| whenever something depends on a function I've changed, even 
| if I don't think the changes were very significant.

But you get many many fewer such unexpected changes when
you do not use -O or (I believe) when you use ghci.   Reason:
without -O ghc exports only type info across module boundaries.

So I'd still
like to understand why Martin is seeing so much recompilation.

S

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



RE: ghc --make feature request

2001-10-29 Thread Simon Marlow

 Simon Marlow [EMAIL PROTECTED] writes:
 
  GHC actually has rather sophisticated recompilation checking which
  goes beyond just checking whether the interface changed - it keeps
  version information for each entity exported by a module and only
  recompiles if any of the entities actually used by the module have
  changed (this is described in the user's guide under the section on
  recompilation checking).
 
 I've seen unexpected compiles using ghc --make.  I've got a system
 with modules A, B, and C; A depends on B and B depends on C.  I've
 seen the following sequence of events:
 
 I change C
 ghc --make A compiles C, B, and A
 I change A
 ghc --make A skips C and compiles B and A
 
 I don't know of any reason why it would have compiled B in the second
 case.
 
 If this is not a known bug, I can try to reproduce it and submit a
 formal bug report.

It's not a known bug, although we have encountered problems of this kind in the past.  
Thanks for the report, we'll look into it.

Cheers,
Simon

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



RE: ghc --make feature request

2001-10-29 Thread Simon Marlow

 Simon Marlow [EMAIL PROTECTED] writes:
 
  GHC actually has rather sophisticated recompilation checking which
  goes beyond just checking whether the interface changed - it keeps
  version information for each entity exported by a module and only
  recompiles if any of the entities actually used by the module have
  changed (this is described in the user's guide under the section on
  recompilation checking).
 
 I've seen unexpected compiles using ghc --make.  I've got a system
 with modules A, B, and C; A depends on B and B depends on C.  I've
 seen the following sequence of events:
 
 I change C
 ghc --make A compiles C, B, and A
 I change A
 ghc --make A skips C and compiles B and A
 
 I don't know of any reason why it would have compiled B in the second
 case.
 
 If this is not a known bug, I can try to reproduce it and submit a
 formal bug report.

From your bug report on SourceForge, it looks like GHC has inferred the wrong 
dependency graph for your program.  It appears that Point.lhs doesn't depend on 
GtkExtra, but nevertheless GHC has decided to compile GtkExtra before Point, but 
after the other dependencies of Point, which would seem to indicate that it thinks 
Point depends on GtkExtra.

If you do a 'ghc --make Point.lhs' (with whatever other options you need), does it try 
to compile GtkExtra?

I tried a small example with similar module structure to your setup, but couldn't 
reproduce the bug.

Cheers,
Simon

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



RE: ghc --make feature request

2001-10-26 Thread Jan-Willem Maessen

Simon Marlow [EMAIL PROTECTED] writes:
 GHC actually has rather sophisticated recompilation checking which
 goes beyond just checking whether the interface changed - it keeps
 version information for each entity exported by a module and only
 recompiles if any of the entities actually used by the module have
 changed (this is described in the user's guide under the section on
 recompilation checking).
 
 So the upshot is that what you're describing shouldn't happen, and it
 may be a bug.  Could you send us more info?

Note that in GHC, the version number of a function can often change
for hard-to-spot reasons.  You just need to change (for example) the
strictness properties of the function, which can be very easy to do
when making changes to your code.  The compiler cares about (much)
more than just the types of imported objects.  I tend to expect
recompiles whenever something depends on a function I've changed, even
if I don't think the changes were very significant.

-Jan-Willem Maessen

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



Re: ghc --make feature request

2001-10-26 Thread Carl R. Witty

Simon Marlow [EMAIL PROTECTED] writes:

 GHC actually has rather sophisticated recompilation checking which
 goes beyond just checking whether the interface changed - it keeps
 version information for each entity exported by a module and only
 recompiles if any of the entities actually used by the module have
 changed (this is described in the user's guide under the section on
 recompilation checking).

I've seen unexpected compiles using ghc --make.  I've got a system
with modules A, B, and C; A depends on B and B depends on C.  I've
seen the following sequence of events:

I change C
ghc --make A compiles C, B, and A
I change A
ghc --make A skips C and compiles B and A

I don't know of any reason why it would have compiled B in the second
case.

If this is not a known bug, I can try to reproduce it and submit a
formal bug report.

Carl Witty

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users