[jhc] Jhc's tangled base

[Samuel Bronson]

On 7/10/07, John Meacham <john at repetae.net> wrote:
> 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.