Jhc's tangled base
Jhc's Prelude seems to be at the center of a giant tangle (SCC) of modules. This tangle of modules takes a *lot* of resources to compile -- I might possibly have gotten it to typecheck once. What's the plan for dealing with it? It almost makes me like GHC's way :-(. It seems like a lot of code would need to be moved to remove more than a couple of modules from the SCC... One problem is that the code to implement Read and Show pulls in Numeric and the list functions currently in Prelude, which pull in a whole bunch of other stuff... including Foreign.Marshal.Utils, Foreign.Marshal.Alloc, Foreign.Ptr, and lots more... Actually, I think the list functions from Prelude could escape the tangle if Maybe didn't derive Read...
On Tue, Jul 10, 2007 at 06:25:29PM -0400, Samuel Bronson wrote:
Jhc's Prelude seems to be at the center of a giant tangle (SCC) of modules. This tangle of modules takes a *lot* of resources to compile -- I might possibly have gotten it to typecheck once. What's the plan for dealing with it? It almost makes me like GHC's way :-(. It seems like a lot of code would need to be moved to remove more than a couple of modules from the SCC...
Yes, this is a known issue and has been getting better with each release. I don't want to make major changes just yet, as the complete rewrite of how numerics will work will change everything. (and has already started to)
One problem is that the code to implement Read and Show pulls in Numeric and the list functions currently in Prelude, which pull in a whole bunch of other stuff... including Foreign.Marshal.Utils, Foreign.Marshal.Alloc, Foreign.Ptr, and lots more...
Actually, I think the list functions from Prelude could escape the tangle if Maybe didn't derive Read...
Yeah, it is a little subtle how to rearrange things properly. another thing is I eventually want to create a smaller 'core' library jhc-foo which will just have the minimum required to compile anything with jhc. which is a lot less than it used to be actually, now that I am getting rid of 'magic' names known by the compiler and actually doing things in the source code. In any case, I don't want to tackle this until separate compilation is working as that will likely change the issues and I don't want to work on two major changes to the same subsystem at once. Also, on a philosophical note, ideally I would just make jhc compile things a whole lot faster rather than try to give it less to compile :) John -- John Meacham - ⑆repetae.net⑆john⑈
On 7/10/07, John Meacham
On Tue, Jul 10, 2007 at 06:25:29PM -0400, Samuel Bronson wrote:
Jhc's Prelude seems to be at the center of a giant tangle (SCC) of modules. This tangle of modules takes a *lot* of resources to compile -- I might possibly have gotten it to typecheck once. What's the plan for dealing with it? It almost makes me like GHC's way :-(. It seems like a lot of code would need to be moved to remove more than a couple of modules from the SCC...
Yes, this is a known issue and has been getting better with each release. I don't want to make major changes just yet, as the complete rewrite of how numerics will work will change everything. (and has already started to)
One problem is that the code to implement Read and Show pulls in Numeric and the list functions currently in Prelude, which pull in a whole bunch of other stuff... including Foreign.Marshal.Utils, Foreign.Marshal.Alloc, Foreign.Ptr, and lots more...
Actually, I think the list functions from Prelude could escape the tangle if Maybe didn't derive Read...
Yeah, it is a little subtle how to rearrange things properly. another thing is I eventually want to create a smaller 'core' library jhc-foo which will just have the minimum required to compile anything with jhc. which is a lot less than it used to be actually, now that I am getting rid of 'magic' names known by the compiler and actually doing things in the source code.
In any case, I don't want to tackle this until separate compilation is working as that will likely change the issues and I don't want to work on two major changes to the same subsystem at once.
I'm not quite sure how better seperate compilation will help to compile such a gigantic "module" as this... I suppose it can't hurt, though ;-).
Also, on a philosophical note, ideally I would just make jhc compile things a whole lot faster rather than try to give it less to compile :)
It doesn't really matter what algorithm you use if you spend all your time waiting for swapping ;-). Though, I suppose you could maybe find an algorithm with good enough locality of reference that it would be nice and snappy.
participants (2)
-
John Meacham -
Samuel Bronson