{"slug": "i-come-to-bury-mod-files-not-to-praise-them", "title": "I come to bury .mod files not to praise them", "summary": "A developer's proposal to replace Fortran .mod files with a per-project database that records every USE statement and each public entity's interface fingerprint would stop unnecessary recompilations at the entity level rather than the file or module level, according to the developer's account of a Claude Code exchange. The developer argues that in a dependency chain A uses B uses C uses D, a change to D's private implementation would halt the recompilation chain at D instead of forcing rebuilds of C, B and A. The proposal contrasts with .mod files, which the developer describes as binary, opaque and forcing an all-or-nothing decision, while the database would handle ONLY-clause filtering and store the consumer's view of the interface.", "body_md": "I asked Claude Code a question:\n\nQ: *btw, thinking about a system to keep Fortran MODULE and SUBMODULE information, I imagine an alternative that uses a per-project (software library or executable) database to keep track not only of timestamps for source files but also of “uses”. For instance, for each MODULE X, the database would record each individual USE statement (naming that same MODULE X) in any other source file/program unit/scope. Can you describe how that would cut down on unnecessary recompilations?*\n\nA: The key insight is that current build systems operate at the wrong granularity – they track file-level or module-level dependencies, but recompilation necessity is determined at the entity interface level. Here is how a USE-tracking database would help:\n\nWHAT THE DATABASE RECORDS\n\nFor every compilation unit that contains a USE statement, it records not just “file B uses module M” but:\n\nFor each module definition, it records the interface fingerprint of every public entity.\n\nHOW UNNECESSARY RECOMPILATIONS ARE ELIMINATED\n\nTHE PROPAGATION ALGORITHM\n\nWhen source file F is recompiled and module M is regenerated:\n\nCOMPOUNDING BENEFIT ACROSS DEEP DEPENDENCY GRAPHS\n\nIn a hierarchy A uses B uses C uses D, a change deep in D affecting only its private implementation would currently force recompilation of C, then B, then A. With the database, the chain stops at D immediately.\n\nRELATION TO EXISTING .MOD FILE APPROACHES\n\n.mod files are binary/opaque and force an all-or-nothing decision. The database reasons at the level of individual entities, handles ONLY-clause filtering, and stores the consumer’s view of the interface rather than just what the module currently exposes.", "url": "https://wpnews.pro/news/i-come-to-bury-mod-files-not-to-praise-them", "canonical_source": "https://fortran-lang.discourse.group/t/i-come-to-bury-mod-files-not-to-praise-them/11128?page=2#post_26", "published_at": "2026-09-28 21:04:18+00:00", "updated_at": "2026-09-28 21:20:05.096507+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence"], "entities": ["Fortran", "Claude Code", "Anthropic"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/i-come-to-bury-mod-files-not-to-praise-them", "markdown": "https://wpnews.pro/news/i-come-to-bury-mod-files-not-to-praise-them.md", "text": "https://wpnews.pro/news/i-come-to-bury-mod-files-not-to-praise-them.txt", "jsonld": "https://wpnews.pro/news/i-come-to-bury-mod-files-not-to-praise-them.jsonld"}}