[MLton] cvs commit: world no longer contains a preprocessed
Mon, 15 Dec 2003 15:16:59 -0500 (EST)
> > > Could we use the import information to do a DFS and mark only the
> > > needed files? Then, we could take the (in order, but too large) file
> > > list produced by CM.Graph.graph and filter out unneeded files.
> > That won't necessarily be minimal:
> I think I understand. We don't have (and cannot recover) dependence
> information at the level of SML files. I.E. we know that main.sml
> uses structure A defined by AB/sources.cm, but we don't know what SML
> file in AB/sources.cm defines structure A. Hence, we cannot remove
> AB/b.sml. Please correct me if I am confused.
That's not quite what I meant. (And I may be misunderstanding what you
implied by the "filter out unneeded files".) It is really a question of
granularity and where/when one decides to do the filtering. With CM, you
get a portable graph per imported "Library" .cm file.
My understanding of your suggestion was to generate each of these graphs.
Then scan all the graphs, noting what structures, signatures, and functors
are imported from each "Library" .cm file. Now, for each graph, eliminate
all the files not necessary for the str, sig, fct required from that
Library .cm file. Finally, output the remaining files in the correct
The problem with this scheme is that collecting the imported str, sig,
fct occurs _before_ doing any filtering. It may later turn out that a
filtering eliminates the need for an imported str, sig, fct.
> It also seems to me like CM must have such information, or at least
> had it in order to do its dependence analysis. It's a shame it's lost
> in the graph.
It's not necessarily lost in the graph. It's just that a portable graph
describes necessary files, not sufficient files. But, we could reasonably
expect CM to generate a tight graph.
> If we had SML-file dependence information, does my filter idea work?
> It's roughly what I was thinking of for mlb files.
I think you'll need to expain your filter idea better. Maybe it does
work, given that one is only ever working with one list of files at a